On Tuesday 10 July 2012 17:30:47 Vishesh Handa wrote: > On Mon, Jul 9, 2012 at 7:18 PM, David Faure <[email protected]> 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, [email protected], http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
