[Nepomuk] [Kde-pim] nepomukqueryservice crash

[David Faure]

On Tuesday 10 July 2012 17:30:47 Vishesh Handa wrote:
> On Mon, Jul 9, 2012 at 7:18 PM, David Faure <faure at kde.org> wrote:
> > On Monday 09 July 2012 16:53:31 Vishesh Handa wrote:
> > > I don't think it's a threading problem cause m_initMutex is locked
> > > before
> > > deleting it, and before accessing it.
> > 
> > That doesn't help. MainModel::executeQuery gets a pointer to a ClientModel
> > inside the lock, and then return an iterator which keeps using that
> > ClientModel outside the lock (or its ClientConnection, more precisely).
> 
> Yes, but the iterator which it receives is of type
> Soprano::Client::ClientQueryResultIterator. This iterator just contains an
> iterator id, and a pointer to the model. Before each operation performed on
> the iterator, it check if the model pointer is not null .. aha!
> The pointer will always be 'not null'.

Yep, it becomes dangling.

> > So this opens the door for crashes, whenever the code that deletes the
> > model is run.
> 
> So you're right, we cannot delete the model.
> 
> Or maybe we could use some kind of pointer wrapper which check for
> deletions. I'm not sure if Qt provides this. Either way it seems messy.

Qt has QPointer/QWeakPointer, but this can't be used in a multithreaded case 
like here, the deletion and the use of the pointer will race. Of course one 
could use a mutex around the use (and the deletion) of the model, then.

But I think it's a bit more complicated, valgrind was pointing to a 
ClientConnection pointer, not to a model pointer.

I'll commit the "don't delete" patch for now, but let's keep looking into this 
:)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5