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

[Seán C. Farley]

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 farley.org>
To: "Greg 'groggy' Lehey" <grog at FreeBSD.org>
Cc: FreeBSD-gnats-submit at FreeBSD.org
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.
 
 --0-1375927335-1109003057=:73374
 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.
 
 Se=E1n
 --=20
 sean-freebsd at farley.org
 --0-1375927335-1109003057=:73374--