Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


Hi Michael and all,

I tried calling disposeAndClear() on mpWindow but the object remains intact
with a lower mnRefCnt of 207. After putting address of mnRefCount on gdb
watch,
it was clear that ref counts gets added for each font added to the font
list box widget while calling the constructor of ImplFontListFontInfo.
In ImplFontListFontInfo the OutputDevice is held inside VclPtr wrapper
(mpDevice) which is never released.
Changing mpDevice  to ordinary pointer, reduced the "residual" refcount of
the window from 207 to 1 after disposeAndClear()
The remaining one reference was held in FontList object whose destructor
call depends on SvxFontNameBox_Impl dtor call, which is our original
problem.
After converting mpDev and mpDev2 in FontList to ordinary pointers,
mpWindow.disposeAndClear() results in calling of
SvxFontNameBox_Impl dtor and now valgrind does not show such a leak.

I also tried to think of a way to do .clear() on these VclPtr wrapped
OutputDevice objects in FontList and ImplFontListFontInfo without having to
change them to
ordinary pointers, but the catch to catch situation of calling
SvxFontNameBox_Impl dtor prevailed. Please suggest any better methods that
I may have missed.

I have submitted an initial patch in gerrit containing these changes.
https://gerrit.libreoffice.org/#/c/18073/

Thanks,
Dennis

On Wed, Aug 26, 2015 at 6:20 PM, Michael Meeks <michael.meeks@collabora.com>
wrote:

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.