[Qt-interest] QMutex deadlock without using QMutex

[Gabriel M. Beddingfield]

On Wed, 28 Apr 2010, K. Frank wrote:

> 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.)

I probably should also have said:  I've found debugging on 
Windows to be really, really painful.  With the GNU tools, 
at least.  YMMV.

>   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.)

^C worked for me from a windows cmd.exe terminal.

However, I usually run GDB through emacs, and there it's
C-c C-c.

> 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?

In UNIX it's usually done by sending SIGSTOP to the 
application.  That's what emacs does when I do C-c C-c.

Another option is to attach to a PID of an already-running 
application.

    $ gdb app.exe PID

Not sure how with Windows.

> 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

Won't be in the stack trace.  Mutexes are usually local 
variables.  When they're locked, they're just plain locked. 
If you want info about what threads hold the locks or which 
line of code locked them or whatever... you'll have to write 
an "extended information" mutex class.

> the os -- if the mutexes are not recursive, so maybe the answer is platform
> dependent, or even an automatic no.)

If you want a recursive mutex, you can simply use a 
semaphore.  In a case like this, I think a recursive mutex 
(or semaphor) would make the situation even harder to solve.

hth,
gabriel