On Wed, October 28, 2015 18:45:40 Olivier Churlaud wrote:
> Le 28/10/2015 16:08, Thomas Lübking a écrit :
> > On Mittwoch, 28. Oktober 2015 14:33:02 CEST, Olivier Churlaud wrote:
> >> Hello
> >>
> >> I finally managed to install the Threadweaver in debug mod.
> >>
> >> Fulltrace in gdb : https://paste.kde.org/pdnashan2
> >>
> >> in valgrind https://paste.kde.org/pwooi9alf
> >>
> >> Thx for your hints
> >
> > W/o even looking at the code (is it pushed somewhere at all?) - you're
> > not explicitly deleting and autodelete (by default) IdDecorator, are you?
> >
> > Cheers,
> > Thomas
>
> The code is pushed on amarok, branch kf5.
>
> IdDecorator is never mentioned anywhere in the code. Only derived classes.
> It works well in the KDE4 environnement (since the amarok devs are able
> to compile it and running it well) but not on the KF5 one. That's why I
> asked it there, because it might be a modification in the library that
> I'm not aware of.
It seems to me that there is a double-deletion going on, likely due to a
manual deletion of the ThreadWeaver job after it is completed at src / core-
impl / collections / db / sql / SqlQueryMaker.cpp:234, and likely also at line
160 with similar reasoning.
Line 234 contains
> void
> SqlQueryMaker::done( ThreadWeaver::JobPointer job )
> {
>
> ThreadWeaver::QObjectDecorator *qs = new
> ThreadWeaver::QObjectDecorator(job.data()); qs->deleteLater();
> d->worker = 0; // d->worker *is* the job, prevent stale pointer
> emit queryDone();
>
> }
In this case ThreadWeaver::JobPointer is a QSharedPointer which means that the
QSharedPointer controls the object lifetime for this sql worker thread.
However the pointer is manually pulled out of the QSharedPointer (by
job.data()) and then manually deleted.
By the time the actual QSharedPointer is ready to delete the pointer, it has
already been deleted thanks to the qs->deleteLater(), which causes the crash
you see.
This is also where you see the "IdDecorator" stuff from: IdDecorator is a
superclass of the QObjectDecorator that was wrapped around d->worker.
From the moment that d->worker was enqueue()'d into ThreadWeaver (in line 212)
Amarok lost control of its object lifetime, and therefore should not attempt
to delete it manually.
Instead just let ThreadWeaver control the object lifetime. If you wish for the
code to work in both the ThreadWeaver and non-ThreadWeaver cases you should at
least also check for d->blocking when manually deleting d->worker.
Regards,
- Michael Pyne
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
