Random crash in QueryMaker::newResultReady()

[Maximilian Kossick]

On Sun, Dec 27, 2009 at 2:25 PM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> On Sun, Dec 27, 2009 at 1:53 PM, Mark Kretschmann <kretschmann at kde.org> wrote:
>> 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?
>>
> I think I've fixed this locally. The problem is that the fix is local
> commit number 50 and depends on at least some of the other commits. I
> might be able to extract a patch, let me check.
>

The attached patch should solve the problem, but please test it, as I
have not been able to reproduce the exact backtrace yet. You still
have to add SqlQueryMakerInternal.cp to CMakeLists.txt, but I cannot
provide a diff for that as my current version of CMakeLists.txt looks
*very* different.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SqlQueryMaker.patch
Type: application/octet-stream
Size: 32795 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20091227/80ca1731/attachment-0001.dll