[Qt-interest] QMutex deadlock without using QMutex

[K. Frank]

Gabriel -

Thanks...

On Wed, Apr 28, 2010 at 10:44 AM, Gabriel M. Beddingfield
<gabrbedd at gmail.com> wrote:
>
>
> On Wed, 28 Apr 2010, K. Frank 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

Okay, I gave this a try on a little Qt application I'm experimenting with.
Looks good.  Wow -- 16 threads!  I see my gui thread (and my code, etc.),
and then 15 other threads, most with ntdll.dll in their call stacks, with a
couple of appearances of kernal32.dll and user32.dll, for good measure.
A bit profligate, perhaps.  I wonder what all those threads are doing.  (By
the way, I'm using mingw32 on 64-bit windows 7.)

> That's what I usually use.  It helps if you have debugging symbols *and*
> source code for your libs. Most of my experience is doing this in Linux.

I do have two questions:

(I'm using gdb, so maybe you can help, but it's mingw, so maybe not.)

First, I ran the program with

   gdb app.exe
   (gdb) run

The app started up and then paused, waiting for ui interaction.
However, I couldn't
run "thread apply all bt" because the gdb prompt didn't reappear while
the app was
paused.  (I tried a random selection of ^C's, <Esc>'s and such, without effect.)

So I reran the program after putting a break point at a line in some
of my widget
code.  When I interacted with the widget in question, the program hit the
break point and control returned to the gdb prompt, so I could run the stack
trace.

My concern is, let's say my program deadlocks (and let's assume I'm running
it under control of the debugger).  Why won't it just hang without
giving control
back to the gdb prompt?  That is, if the program deadlocks, how do I make
sure I can get to the gdb prompt to run the stack trace?

Second, I don't see anything in the stack traces that shows what mutexes
are held by a thread (not that I necessarily should in this test case).
Certainly in a deadlock situation, I should see something like

   acquire_mutex(): line 123

at the top of the stack trace, but it's very helpful to know which locks are
already held by a thread when debugging a deadlock.  Is this information
accessible with gdb?  (Note, the information about which threads hold which
mutexes may not even be stored anywhere -- neither in the application nor
the os -- if the mutexes are not recursive, so maybe the answer is platform
dependent, or even an automatic no.)

As you can tell, I'm pretty new to gdb, so I appreciate your sharing with me
some of the tricks of the trade.

> -gabriel

Thanks.


K. Frank