This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Multi-threaded debugging within GDB & eCOS
- To: alexs at cygnus dot co dot uk
- Subject: Re: Multi-threaded debugging within GDB & eCOS
- From: Stan Shebs <shebs at cygnus dot com>
- Date: Thu, 2 Dec 1999 19:05:25 -0800
- CC: gdb at sourceware dot 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