[Qt-interest] QMutex deadlock without using QMutex

[K. Frank]

Gabriel -

Thanks for the pointers.

On Wed, Apr 28, 2010 at 2:20 PM, Gabriel M. Beddingfield
<gabrbedd at gmail.com> wrote:
>
> On Wed, 28 Apr 2010, K. Frank wrote:
>
>>  (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.

Hmm...  Maybe that's why I'm not so experienced with gdb.  I've tried using
gdb casually (on windows -- cygwin, and more recently mingw) a few times
over the years, but always ran into to some difficulty or another, and never
kept at it long enough to learn the ropes.

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

Odd.  I tried it again, and it worked (that is, ^C in cmd.exe).  But
it took about five
seconds to show the gdb prompt, so I assumed that maybe I had just been a little
too impatient.  So I tried it three or four more times and it didn't
work.  As I played
around, ^C seemed to work sporadically, and would sometimes take effect after I
"bumped" the application, interacting with its gui somehow.

The only recipe I've found for reliably getting to the gdb prompt is
to use ^C, and
then click on my application's File menu.  And this only works reliably from a
fresh start of the app.  If I ^C (and click on File), and then enter
the continue
command at the gdb prompt, ^C followed by clicking on File usually doesn't
work (although other interactions with the gui will sometimes cause the ^C to
take).

Well, unless someone thinks that this is likely to be a Qt-specific issue, if I
decide to follow up on in, I'll take it over to the mingw list.

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

Yes, that's certainly consistent with my understanding of linux (and windows).
In java, that "extended information" is built in (into the mutex or
the vm or both).
It's certainly helpful when debugging deadlocks, but obvious carries along some
costs with it.

(Although, it's kind of too bad we don't have this "extended information" mutex
out of the box.  To try to make this post on-topic, coming back to Andre's
original post, if you had the stack traces together with the held mutexes, there
is a reasonable chance that one careful look at them would take you right to
the root cause of the deadlock.)

> ...
> hth,
> gabriel

Yes it does; thanks.

K. Frank