Random crash in QueryMaker::newResultReady()

[Maximilian Kossick]

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.