Hamish Rodda rodda at
Thu Dec 1 21:07:27 GMT 2005

On Friday 02 December 2005 07:29, Aaron J. Seigo wrote:
> On Thursday 01 December 2005 13:03, you wrote:
> > Hmm, not saying I understand the issue at hand, but can't kicker use
> > guarded pointers to these classes and KDirListerCache makes sure the
> > attached listeners are deleted ?
> the issue is that kicker right now relies on static object deletion (due to
> the use of singleton in the menu manager) to get rid of the kmenu(s) that
> are around. and there are klibloader loaded items.
> klibloader relies on static object deletion to clean up objects that
> haven't been deleted yet.
> kdirlister relies on static object deletion to clean up caches.
> we could modify any of those three, and i did. and did so in a way that
> generally works and works well. i modified kdirlister because it was able
> to guard against the pathological case (which can result in further
> complications in even MORE pathological cases that build on the simple
> pathological case, which is michael's concern (and why i think it's not a
> matter of real concern)).
> i don't think it is good design for the libraries to impose requirements
> (which also happen to be undocumented) on app developers due to internal
> implementation decisions made in the libs.
> bottom line: my fix works. it was reverted against my wishes (but in
> accordance with michael's, obviously =) on theoretical grounds. and i
> really think that in this particular case, the pragmatic fix is the right
> one.
> i could probably hack around this one particular case in kicker, but i'm
> fairly confident it would just crop up again elsewhere. i don't like fixing
> symptoms.

I believe I know of an similar case of this - kdevelop crashes on shutdown of 
KDE (but not when the user quits), bug 82311.  It is also an interaction 
between the order of klibloader vs kdirlister cleanup.  I tried to fix it in 
the app - eventually I had to throw out my branch because of all the hacks I 
tried to add to get around it.  Here's the relevant valgrind output:

==9616== Invalid read of size 8
==9616==    at 0x704CD7B: KFileIconViewItem::~KFileIconViewItem() 
(in /opt/kde/lib/
==9616==    by 0x8B001BC: QIconView::~QIconView() 
(in /usr/lib/
==9616==    by 0x704F0FF: KFileIconView::~KFileIconView() 
(in /opt/kde/lib/
==9616==    by 0x706205E: KDirOperator::~KDirOperator() 
(in /opt/kde/lib/
==9616==    by 0xE5B18CA: KDevDirOperator::~KDevDirOperator() 
==9616==    by 0x8953B65: QWidget::~QWidget() (in /usr/lib/
==9616==    by 0xE5AF3C8: KDevFileSelector::~KDevFileSelector() 
==9616==    by 0xE5A8B8F: FileSelectorPart::~FileSelectorPart() 
==9616==    by 0x8BF9467: QGList::clear() (in /usr/lib/
==9616==    by 0x7B28F18: KLibrary::~KLibrary() 
(in /opt/kde/lib/
==9616==    by 0x7B2802A: KLibLoader::close_pending(KLibWrapPrivate*) 
(in /opt/kde/lib/
==9616==    by 0x7B29AF9: KLibLoader::~KLibLoader() 
(in /opt/kde/lib/
==9616==    by 0x7B26AF5: KLibLoader::cleanUp() 
(in /opt/kde/lib/
==9616==    by 0x7A76EE4: KApplication::~KApplication() 
(in /opt/kde/lib/
==9616==    by 0x4084D5: main (main.cpp:145)
==9616==  Address 0x137B1318 is not stack'd, malloc'd or (recently) free'd

The patch being discussed doesn't seem to fix the kdevelop issue however 
(unless there is more than just that one revision which was reverted).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list