[Qt-interest] QMutex deadlock without using QMutex

[Andre Somers]

On 27-4-2010 18:04, Andre Somers wrote:
> On 27-4-2010 17:49, Brad Howes wrote:
>    
>> On Apr 27, 2010, at 11:32 AM, Andre Somers wrote:
>>
>>
>>      
>>> After setting a breakpoint at the two places where this error can be
>>> triggered (qmutex.cpp lines 162 and 200; Qt 4.6.2) I managed to get a trace:
>>>
>>> 0    QMutex::lock    qmutex.cpp    201    0x00e10f4e
>>> 1    QMutexLocker::relock    qmutex.h    120    0x00f5c564
>>> 2    QMutexLocker    qmutex.h    102    0x00f5c604
>>> 3    QCoreApplicationPrivate::sendPostedEvents
>>> qcoreapplication.cpp    1271    0x00efe127
>>> 4    qt_internal_proc    qeventdispatcher_win.cpp    482    0x00f1f73f
>>> 5    USER32!DefDlgProcW    C:\WINDOWS\syswow64\user32.dll    0
>>> 0x7d9472d8
>>> 6    ??        0    0x003f06a8
>>> 7    ??        0    0x00000401
>>> 8    ??        0    0x00000000
>>>
>>> Following the item at line 3, I notice that Qt is indeed using a mutex
>>> for the message passing. So, it seems we are dealing with Qt's mutex,
>>> not mine.
>>>
>>>        
>> Are your trying to do more signalling while you are responding to a signal? Not knowing the internals, I would hazard a guess that that could cause a (self) deadlock. QMutex supports recursive locking, but I have no idea if the QMutex used in sendPostedEvents was created in that manner.
>>
>>      
> I am. When I get a signal from a worker thread, the work manager thread
> sends a signal back to the worker thread with a new work package.
> Additionally, it may send signals with progress information to the UI.
> What may be noteworthy here, is that for the signaling of the worker
> thread, I am not actually using a signal. I am using
> QMetaObject::invokeMethod with the QueuedConnection argument. This
> allows me to easily send the message only to a specific worker thread.
>    

An observation that may be relevant:
The calculation I am running, is part of a whole series of calculations 
(basically a workflow). I use another instance of the same component in 
this particular workflow. This other instance operates on different data 
that takes longer to process per work package; about 4 or 5 times longer 
on average it seems (1,3M calculations per second vs. around 6M). This 
other component does not have the same problem; it can run happily for 
half an hour without a hickup. The component that has faster processing 
times consistently freezes at around the same moment in the calculation, 
though not all worker threads deadlock at the same time. It sometimes 
happens that one worker thread continues to deliver results and get new 
packages for a little while untill that last one deadlocks too. That 
freezing up happens after a few minutes, after each worker has processed 
in the order of magnitude of 500 packages (and thus the same number of 
round trips between the work manager thread and each of the worker 
threads).

André