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.

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).


- 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/20101116/912f03ad/attachment.htm>