Deletion of vcl::Window's inside ToolBar

[Dennis Francis]

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 at 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 at collabora.com  <><, Pseudo Engineer, itinerant idiot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150828/b9c82559/attachment.html>