gnu/77818: GDB locks in wait4() when running applications

Seán C. Farley sean-freebsd at
Mon Feb 21 16:30:23 GMT 2005

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

From: =?ISO-8859-1?Q?Se=E1n_C=2E_Farley?= <sean-freebsd at>
To: "Greg 'groggy' Lehey" <grog at>
Cc: FreeBSD-gnats-submit at
Subject: Re: gnu/77818: GDB locks in wait4() when running applications
Date: Mon, 21 Feb 2005 10:24:17 -0600 (CST)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: QUOTED-PRINTABLE
 On Mon, 21 Feb 2005, Greg 'groggy' Lehey wrote:
 > On Sunday, 20 February 2005 at 19:15:01 -0600, Sean Farley wrote:
 >>> Synopsis:       GDB locks in wait4() when running applications
 >>> Description:
 >> Whenever I run an application through the system's GDB, GDB locks in
 >> wait4().  It does not matter if the application has debugging
 >> information or not.  /bin/ls will lock GDB up for me until I type
 >> Ctrl-C.
 > Is this an SMP system?
 Neither system is SMP nor using HyperThreading.  sysctl shows that the
 systems believe they only have one CPU (as expected).
 >> Two systems of mine exhibit this behavior.  One has the binary nvidia
 >> driver with a lot of changes in libmap.conf.  The other is headless
 >> without a libmap.conf.
 > I've found something similar with SMP systems only.  It wasn't as
 > consistent as the way you describe, and I was able to work around the
 > problem by turning off all but one CPU.  See kern/77537 for more
 > details.
 It does sound similar.  I wonder if it was something MFC'd from CURRENT,
 but I do not remember when it started hanging.
 sean-freebsd at

More information about the freebsd-bugs mailing list