Random crash in QueryMaker::newResultReady()

[Mark Kretschmann]

On Sun, Dec 27, 2009 at 1:48 PM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> On Sun, Dec 27, 2009 at 8:04 AM, Mark Kretschmann <kretschmann at kde.org> wrote:
>> On Sun, Dec 27, 2009 at 7:56 AM, Mark Kretschmann <kretschmann at kde.org> wrote:
>>> On Sun, Dec 27, 2009 at 1:16 AM, Alex Merry <kde at randomguy3.me.uk> wrote:
>>>> I had a lot of locking crashes the other week, including this one, I think.
>>>> Most of them were in libdbus, though.  It appeared to go away last time I
>>>> updated my KDE (trunk) build, though (I didn't update Qt).
>>>
>>> FWIW, I just found out that this crash seems to happen with several Qt
>>> versions (myself I used 4.5.3) and KDE versions, and we even got a
>>> "release_blocker" bug report for it, so it seems to be rather common:
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=215684
>>
>> Looking at the backtrace again, I wouldn't be surprised if were
>> dealing with some kind of dangling pointer here. The QMutex call might
>> be a red herring.
>>
>> What might actually happen is that the handleResult() or
>> newResultReady() SLOTs are called on an object that was already
>> destroyed, I think. Sadly Qt does not automatically remove connections
>> to destroyed objects.
>
> I don't think we are calling the slots on an object that was
> destroyed. The bug reports consistently state that Amarok crashes
> while filtering in the collection. The CollectionTreeModel (which the
> querymaker signals are connected to) is not deleted. I think what
> happens here is that the QueryMaker object is deleted while the query
> is still running in a thread, and Amarok crashes when it tries to emit
> the results for that query from the (non-GUI) thread.

Hmm yep, that might be it. Any ideas for fixing this easily?

-- 
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
www.kde.org - amarok.kde.org - www.fsfe.org