gnu/77818: GDB locks in wait4() when running applications
davidxu at freebsd.org
Wed May 25 06:10:10 GMT 2005
The following reply was made to PR gnu/77818; it has been noted by GNATS.
From: David Xu <davidxu at freebsd.org>
To: bug-followup at freebsd.org, sean-freebsd at farley.org
Subject: Re: gnu/77818: GDB locks in wait4() when running applications
Date: Wed, 25 May 2005 14:08:51 +0800
> I have a new test program that I think shows the problem. My
> previous program actually showed another bug that has since been fixed.
> Actually, it shows two problems. When run within the debugger
> (SHELL=3D/bin/sh gdb a.out), the parent will be stuck waiting for a signal
> it will never receive in sigsuspend().
Please try following patch, I believe the old hack is incorrect now
with jhb's sleep queue.
RCS file: /home/ncvs/src/sys/kern/kern_thread.c,v
retrieving revision 1.215
diff -u -r1.215 kern_thread.c
--- kern_thread.c 23 Apr 2005 02:32:31 -0000 1.215
+++ kern_thread.c 25 May 2005 06:01:00 -0000
@@ -929,14 +929,6 @@
TAILQ_INSERT_TAIL(&p->p_suspended, td, td_runq);
- * Hack: If we are suspending but are on the sleep queue
- * then we are in msleep or the cv equivalent. We
- * want to look like we have two Inhibitors.
- * May already be set.. doesn't matter.
- if (TD_ON_SLEEPQ(td))
> The other problem is that nanosleep() is exiting immediately with a
> return of zero although the time to sleep has not passed. To see it do
> this, remove the BROKEN_NANOSLEEP_WITHIN_GDB definition at the top of
> the program and recompile.
This is a long history bug, I believe it is still in RELENG_4. Now the
bug is in
kern_sig.c: do_tdsignal(), when process is being debugged, a masked
signal can wake up
a sleeping thread! that's why it is broken.
More information about the freebsd-bugs