Review Request: Make sure to remove KXMLGUIClients from factory on destruction

[David Faure]

> On 2010-07-03 22:44:14, David Faure wrote:
> > I was initially against this kind of thing (too many problems with "intelligent" destructors), this is why it hasn't been done before.
> > But after long consideration, I think this one is safe and, as you say, somewhat expected by users of the framework, so I'm ok with it.
> > I'll commit it to trunk, at least, we'll see if it proves stable enough for 4.5.0.
> > Thanks a lot for the patch, and sorry for the delay.
> 
> David Faure wrote:
>     Turns out I was right, the "intelligent destructor" creates trouble - bug 246652 :-)
>     I think I'll make it a bit less intelligent (it should make the factory forget this client, but it should not unplug actions one by one).
> 
> Thomas Friedrichsmeier wrote:
>     Hm. I didn't look too closely at what ContainerNode::destruct() does. But on first glance this sounds like there will be a memory leak if a client is deleted without being removed, first, now.
>     
>     *If* so, that's still better than causing a seemingly unrelated crash a long time later. But perhaps there should be a debug message telling developers to fix their object destruction order, whenever a client still has a factory while being deleted (and for KDE 5, we might consider reducing the smartness even further to simply crashing right there and then).
> 
> Matthias Fuchs wrote:
>     Forgive me my complete ignorance -- as I haven't looked at the code -- but couldn't smart pointers solve some of the problems encountered here?

Matthias: let's actually identify problems before we start talking about solutions :)

Thomas: I just checked with kxmlgui_unittest, and there is no leak (now that I fixed a unittest-specific issue with the parent of the KMenus), once the mainwindow is destroyed.
The ContainerNode themselves are destroyed in ~KXMLGUIFactoryPrivate.

I agree though, that there is a small risk for a leak, in more corner cases, like standalone popupmenus which get no parent widget. And I agree too that the best solution is to just leave that in, but warn when someone deletes a client without removing it from the factory first -- which crashed before, so a warning is already much better :) I'll do that.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/4126/#review6354
-----------------------------------------------------------


On 2010-06-01 07:15:25, Thomas Friedrichsmeier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/4126/
> -----------------------------------------------------------
> 
> (Updated 2010-06-01 07:15:25)
> 
> 
> Review request for kdelibs, Christoph Feck and David Faure.
> 
> 
> Summary
> -------
> 
> Under some circumstances, dangling pointers to deleted KXMLGUIClients may remain in the list of a KXMLGUIFactory's clients. Usually, KXMLGUIClients are also KParts, and managed by a KPartManager. If everything goes as expected, the KPartManager detects when the active KPart is destroyed, and the KParts::MainWindow takes care of removing it from the factory. When XMLGUIClients are nested, things may not always go as smoothly. KXMLGUIFactory::removeClient() removes clients recursively, however, if one of the child clients gets destroyed before the parent KParts was removed from the factory, it will be taken out of the parent client's list of children, but not out of the factory's list of clients. Possibly, there are other subtle cases, where dangling pointer remain in KXMLGUIFactory::clients(). Naturally this will lead to crashes, when code tries to do something with all clients of the factory. The listed bugs are symptoms of this cause (at least potentially; with non-reproducible bugs it's always hard to tell, whether there was only a single cause).
> 
> Probably this issue is addressable in the respectively parts / applications, by making sure that any child clients are not deleted before the toplevel part is removed from the factory. However, it is possible, and sensible to add code in the KXMLGUIClient d'tor to make sure that the factory will never keep dangling pointers. This patch does so. Some additional code is needed to make sure that this does not cause trouble during application exit, by making sure that the KXMLGUIFactory is deleted before the KXMLGUIBuilder, and remaining clients no longer assume a factory.
> 
> Note:
> Bug #170806 contains a valgrind log, and reproducible instructions on crashing kontact, which can probably be mapped to other affected applications.
> 
> 
> This addresses bugs 170806, 183338, 205625, and 212397.
>     https://bugs.kde.org/show_bug.cgi?id=170806
>     https://bugs.kde.org/show_bug.cgi?id=183338
>     https://bugs.kde.org/show_bug.cgi?id=205625
>     https://bugs.kde.org/show_bug.cgi?id=212397
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/kdeui/tests/kxmlgui_unittest.h 1129152 
>   trunk/KDE/kdelibs/kdeui/tests/kxmlgui_unittest.cpp 1129152 
>   trunk/KDE/kdelibs/kdeui/xmlgui/kxmlguiclient.cpp 1129152 
>   trunk/KDE/kdelibs/kdeui/xmlgui/kxmlguifactory.cpp 1129152 
>   trunk/KDE/kdelibs/kdeui/xmlgui/kxmlguiwindow.cpp 1129152 
> 
> Diff: http://svn.reviewboard.kde.org/r/4126/diff
> 
> 
> Testing
> -------
> 
> Fixes crashes during toolbar / shortcut configuration for RKWard.
> 
> Results of existing unit tests are not affected. New unit test added.
> 
> Tested on trunk, only. If this should go into 4.4, I'd like someone else to do the commit on the branch.
> 
> 
> Thanks,
> 
> Thomas
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101117/5d705f1e/attachment.htm>