KStaticDeleter Kicker Crash

[Aaron J. Seigo]

On Friday 16 September 2005 19:06, Michael Pyne wrote:
> Speaking from a Computer Science point of view, the "best" way I can think
> of would be to create a throwaway class that, when destructed, will
> destruct the two static objects in the correct order, and then use only one
> KStaticDeleter on an instance of your throwaway class.

this is a good idea, but the code in KickerSettings is autogenerated 
(KConfigXT) and due to that uses KStaticDeleter. not much i can do about that 
without changing (or adding to) the semantics of KConfigXT at this point.

> It hurts to ask this, but is it required that these be deleted?  If they
> live for the lifetime of kicker it may be easier just to have the kernel
> reclaim the memory.  It's going to do so anyways when kicker exits. ;)

it's not about reclaiming memory, it is running dtor's of objects including 
those in the QObject parent/child tree. there may be some classes there that:

	have no children ever, guaranteed
	need to do nothing in the dtor ever, guaranteed

due to this not being true in many cases, it caused problems in previous 
releases.

what i could do is move away from using KStaticDeleters in places like 
ExtensionManager ... =/ instead, they'd all have to be destroyed in 
Kicker::~Kicker() ... this couples things tighter than i'd really like in 
that one place but that may be the only solution =(

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050916/cb1292f9/attachment.sig>