[Qt-interest] QMutex deadlock without using QMutex

[K. Frank]

Bill -

On Wed, Apr 28, 2010 at 11:02 AM, william.crocker at analog.com
<william.crocker at analog.com> wrote:
>
>>
>>> My question is what are good debugging tools to get this kind of information?
>>> ...
>> gdb will give you a backtrace of all your threads... even
>> from a core dump.
>>
>>     thread apply all bt
>> ...
> ...and if the process is frozen and you see one thread waiting
> for a mutex you can surmise that one of the other threads is
> currently holding it. Two threads waiting for different mutii
> is just icing on the cake.

I would like to expand on this a little bit:

If your app hangs and you see a thread waiting to acquire a mutex,
it is indeed a good bet that you have a deadlock and that another
thread is holding the mutex for which the first is waiting.

But I would say that seeing two threads waiting for a pair of mutexes
(or seeing a potentially more complicated multi-thread scenario) can
be more than icing on the cake -- it can be key to debugging the cause
of the deadlock.

Consider the classic deadlock example mentioned before, where threads
A and B both attempt to acquire mutex_1 and mutex_2, but in the opposite
order from one another, so they deadlock.

Now suppose that before deadlocking, thread A legitimately acquired mutex_3.
Furthermore, let's say that after the deadlock occurs, thread C (Note, the app
is not yet completely frozen -- threads other than A and B may still be running
and interacting with the user.) attempts to acquire mutex_3, and blocks.
Let's also say that thread C is your gui thread, so now the app visibly hangs,
you run your stack trace, and you see that thread C is waiting for mutex_3.

Unfortunately, this doesn't tell you anything about the cause of the deadlock.
Thread C and mutex_3 are "innocent bystanders" in this case.  The bug that
caused the deadlock was the incorrect way in which threads A and B interacted
with mutex_1 and mutex_2 (and even thread A's acquisition of mutex_3 was
legitimate, and not a bug).

Seeing thread A, thread B, mutex_1, and mutex_2 all together in their "deadly
embrace" is the debugging information you really want to be able to get your
hands on.  Thread C waiting for mutex_3 is a symptom, but not the cause.

> Bill

Best.


K. Frank