Hi Dennis,
On Wed, 2015-08-26 at 17:59 +0530, Dennis Francis wrote:
After entering ToolBarManager::RemoveControllers, I put a break point
on SvxFontNameBox_Impl::~SvxFontNameBox_Impl and then did
mpWindow.clear() in gdb (where mpWindow is the SvxFontNameBox_Impl
object wrapped in VclPtr).
Interesting. Is it possible that there should be a disposeAndClear
there ?
But gdb did not show a call on the dtor ~SvxFontNameBox_Impl. After
further digging, I found that the mnRefCnt of the mpWindow in question
was 219 just before the VclPtr was reset.
So - for a given un-disposed window - I'd expect lots of VclPtr
references - but its unusual to have that many.
Now I wonder who else increased the ref count of this mpWindow object,
why the value is so high and how to proceed from here ?
VCL itself maintains a whole slew of these - eg. the impl. of a window
points to the next window, the previous window, top-levels are
maintained in lists left & right etc. parents hold references to
children and vv. (depends how many children it has).
In order to (hopefully) break all these referencing cycles - it is
necessary to call 'disposeOnce' or 'disposeAndClear' on the VclPtr -
which stats the process of tidying up all the references.
I miss the context but reading vcl/README.lifecycle would
probably be helpful.
HTH,
Michael.
--
michael.meeks@collabora.com <><, Pseudo Engineer, itinerant idiot
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.