From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2247 invoked by alias); 27 Apr 2005 22:51:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2063 invoked from network); 27 Apr 2005 22:51:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 27 Apr 2005 22:51:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DQvMz-000053-81; Wed, 27 Apr 2005 18:51:01 -0400 Date: Wed, 27 Apr 2005 23:33:00 -0000 From: Daniel Jacobowitz To: Andreas Schwab Cc: David Lecomber , gdb Subject: Re: GDB locks up -- Cannot find new threads: generic error Message-ID: <20050427225101.GA32735@nevyn.them.org> Mail-Followup-To: Andreas Schwab , David Lecomber , gdb References: <1114627357.31720.81.camel@cpc4-oxfd5-5-0-cust111.oxfd.cable.ntl.com> <20050427190108.GA28978@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00205.txt.bz2 On Thu, Apr 28, 2005 at 12:46:26AM +0200, Andreas Schwab wrote: > Daniel Jacobowitz writes: > > > On Wed, Apr 27, 2005 at 07:42:37PM +0100, David Lecomber wrote: > >> (gdb) b main > >> Breakpoint 1 at 0x804ed18: file > >> main.cpp, line 10. > >> (gdb) run > >> Starting program: a.out > >> warning: linux_test_for_tracefork: unexpected result from waitpid > >> (28261, > >> status 0x117f) > >> [Thread debugging using libthread_db enabled] > >> Error while reading shared library symbols: > >> Cannot find new threads: generic error > >> > >> at this point GDB does nothing and is unresponsive to any user input. > >> > >> The system is: > >> kernel-2.4.21-27.EL > >> glibc-2.3.2-95.30 > > > > At a guess, your kernel is buggered. You really should never see that > > warning. The unexpected signal is SIGCHLD; your kernel has accepted > > the SETOPTIONS but obviously failed to stop when the test thread > > vforked. > > I think that can happen when the 32 bit ptrace emulation is incomplete, > especially if PTRACE_GETEVENTMSG is not properly emulated. That should be > fixed in recent (< 9 months) kernels. That's quite possible; thank you for the information. Maybe we can improve the test to detect the problem more easily. Any suggestions? -- Daniel Jacobowitz CodeSourcery, LLC