[Nepomuk] Bug 292996

[Simeon Bird]

Hi everyone,

I think I figured out Bug 292996 (crash in Nepomuk2::~Resource).

So the problem is that kontact has a class,
NepomukResourceRetrieverRunnable, which inherits from QRunnable, and
creates a Resource on the stack of it's QThread.

But, unknown to it, it is actually getting a reference to a Resource stored
by the ResourceManager, which has QApplication as a parent.

When kontact exists, it deletes ResourceManager.

But at this point the QRunnable has not yet been stopped,
because the caller assumes that they have allocated
Nepomuk::Resource on the QThread stack, and are not aware
that it is secretly shared with the other threads via
the singleton class in ResourceManager.

The QRunnable persists, but now resources don't point to anything.

Boom! Crash.

Ok, so that's the crash.

There are two possible fixes:

The first is just to have the ResourceManager destructor check the
ref-count for all its resources in a loop and not go away anything until
they are all zero. This is fairly non-invasive but ugly.

The second is: do we really need to share the Resources in a singleton
class anyway? So far as I can see, it's only there to speed up multiple
accesses to the same resource, which I would imagine is quite rare in
practice (most people will want multiple different resources). If most of
the time the reference count on the resources is 1, it will be faster just
to allocate them directly because we won't be doing the whole locking dance
around ResourceManager, nor will we need to search all previously allocated
Resources.

Someone who uses kmail (I don't) could check this fairly easily by adding
debug statements that print the maximal reference count of each Resource a
few times...

Or am I missing some other feature of keeping the Resources in
ResourceManager?

Even if the second fix is a good idea, it seems too big a change to
implement this close to release, so I was thinking the first fix for 4.10,
and the second for 4.11. What do you think?

Simeon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121203/2530747e/attachment.html>