Re: Multi-threaded debugging within GDB & eCOS

[Stan Shebs <shebs at cygnus dot com>]

   From: "Alex Schuilenburg" <alexs@cygnus.co.uk>
   Date: Thu, 14 Jan 1999 11:04:23 -0000

   Could someone describe how gdb would handle the following situation in
   debugging multiple threads using gdb (particularly on eCOS)? Has anyone
   thought of this scenario before?

   1) gdb is tracking thread A, which claims a system mutex.
   2) Either a context switch occurs or the user suspends thread A and
      switches to debugging thread B (which itself is suspended).
   3) While stepping over fn calls within B, the code attempts to claim
      the mutex already owned by A. Hence B will never return from the call
      to the next temporary breakpoint until A is resumed and releases the
      mutex.

   Will gdb lock up? Is there any mechanisim to allow gdb to detect/catch this
   scenario and report back to the user what has happened?

GDB will "lock up".  More precisely, GDB will sit quietly waiting for
the target to do something, not realizing that the user has caused a
deadlock by manually suspending thread A.  This is as expected, since
GDB has no way to know that the program is in this state.  In
practice, the user gets impatient, hits ^C, sees the current state,
and goes "oh yeah, my fault" and fixes.

GDB's default behavior is to give all threads a chance to run when
resuming, which generally prevents this kind of situation.  We
introduced the scheduler-locking flag for those cases where the user
really really needs to lock out other threads, even if it might mean
the thread being stepped will block.

(I'd be interested to know if you have workarounds for this
fundamental problem though.)

								Stan