On Thu, Oct 29, 2015 at 7:23 AM, Michael Pyne <mp...@kde.org> wrote:
> 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.
>
>
Hello,
> 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();
> >
> > }
>
I have deleted the parts where threadweaver::job was being manually deleted
and now its working fine
here are the changes i have made https://git.reviewboard.kde.org/r/125872/
>
> 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.
>
>
thank you so much for your help :)
> Regards,
> - Michael Pyne
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
