<div dir="ltr"><div><div>Hi Michael and all,<br><br>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,<br>it was clear that ref counts gets added for each font added to the font list box widget while calling the constructor of ImplFontListFontInfo.<br>In ImplFontListFontInfo the OutputDevice is held inside VclPtr wrapper (mpDevice) which is never released.<br>Changing mpDevice  to ordinary pointer, reduced the "residual" refcount of the window from 207 to 1 after disposeAndClear()<br>The remaining one reference was held in FontList object whose destructor call depends on SvxFontNameBox_Impl dtor call, which is our original problem.<br>After converting mpDev and mpDev2 in FontList to ordinary pointers, mpWindow.disposeAndClear() results in calling of<br>SvxFontNameBox_Impl dtor and now valgrind does not show such a leak. <br><br>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<br></div><div>ordinary pointers, but the catch to catch situation of calling SvxFontNameBox_Impl dtor prevailed. Please suggest any better methods that I may have missed.<br></div><div><div><span class="im"><br></span></div><div>I have submitted an initial patch in gerrit containing these changes.<br><a href="https://gerrit.libreoffice.org/#/c/18073/">https://gerrit.libreoffice.org/#/c/18073/</a><span class="im"><br></span></div><br></div>Thanks,<br></div>Dennis<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 6:20 PM, Michael Meeks <span dir="ltr"><<a href="mailto:michael.meeks@collabora.com" target="_blank">michael.meeks@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dennis,<br>
<span class=""><br>
On Wed, 2015-08-26 at 17:59 +0530, Dennis Francis wrote:<br>
> After entering ToolBarManager::RemoveControllers, I put a break point<br>
> on SvxFontNameBox_Impl::~SvxFontNameBox_Impl and then did<br>
> mpWindow.clear() in gdb (where mpWindow is the SvxFontNameBox_Impl<br>
> object wrapped in VclPtr).<br>
<br>
</span>        Interesting. Is it possible that there should be a disposeAndClear<br>
there ?<br>
<span class=""><br>
> But gdb did not show a call on the dtor ~SvxFontNameBox_Impl. After<br>
> further digging, I found that the mnRefCnt of the mpWindow in question<br>
> was 219 just before the VclPtr was reset.<br>
<br>
</span>        So - for a given un-disposed window - I'd expect lots of VclPtr<br>
references - but its unusual to have that many.<br>
<span class=""><br>
> Now I wonder who else increased the ref count of this mpWindow object,<br>
> why the value is so high and how to proceed from here ?<br>
<br>
</span>        VCL itself maintains a whole slew of these - eg. the impl. of a window<br>
points to the next window, the previous window, top-levels are<br>
maintained in lists left & right etc. parents hold references to<br>
children and vv. (depends how many children it has).<br>
<br>
        In order to (hopefully) break all these referencing cycles - it is<br>
necessary to call 'disposeOnce' or 'disposeAndClear' on the VclPtr -<br>
which stats the process of tidying up all the references.<br>
<br>
        I miss the context but reading vcl/README.lifecycle would<br>
probably be helpful.<br>
<br>
        HTH,<br>
<br>
                Michael.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
 <a href="mailto:michael.meeks@collabora.com">michael.meeks@collabora.com</a>  <><, Pseudo Engineer, itinerant idiot<br>
<br>
</font></span></blockquote></div><br></div>