This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb/1356: Threads not handled properly when returning from breakpoint


The following reply was made to PR gdb/1356; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@mvista.com>
To: rtrask@broadcom.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/1356: Threads not handled properly when returning from breakpoint
Date: Thu, 28 Aug 2003 14:32:39 -0400

 On Thu, Aug 28, 2003 at 06:22:28PM -0000, rtrask@broadcom.com wrote:
 > >Environment:
 > Linux, Redhat 7.1
 > >Description:
 > When running a multi-threaded program gdb erroneously awakens (all) sleeping threads when returning from a breakpoint in another thread.
 > I have a small file "alarm_thread.c" (from David Butendorf's Programming with Posix Threads) that demonstrates this.
 > This program works properly outside of gdb.
 
 > {enter alarm duration and "name" at the Alarm> prompt, bp will hit just after entry and before creating thread to handle alarm timer. Make sure to enter large enough times e.g. 300 seconds so that alarm expiration will not occur)
 > Enter multiple alarms, note that alarms previously entered will report even though their timers have not expired.
 > You can check status using info threads et al and discover threads that were created and sleeping on [entered timeouts] have disappeared after returning from the breakpoint.
 > This occurs no matter how I return from the breakpoint, either by hitting "c" or "thread apply <thread num> c".
 > I have tried this with the most current version of gdb and the weekly snapshot, behavior is the same.
 > If someone has a fix or proposed patches I am willing to try them out and report results.
 
 This is not a GDB bug.
 
 It's actually complicated to decide whether it's a bug at all; I tend
 to think it is, but a lot of people didn't agree with me.  In any case,
 if you use a 2.6-series Linux kernel instead of the older one you're
 running, it should go away.
 
 When GDB stops and restarts the thread, nanosleep is interrupted.  But
 no signal is delivered, so the application can not tell why.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]