Re: threads/1154: gdb-5.3 + glibc-2.3.2 fail for my multithreaded program

[Daniel Jacobowitz <drow at mvista dot com>]

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

From: Daniel Jacobowitz <drow at mvista dot com>
To: mat at lcs dot mit dot edu
Cc: gdb-gnats at sources dot redhat dot com
Subject: Re: threads/1154: gdb-5.3 + glibc-2.3.2 fail for my multithreaded program
Date: Thu, 27 Mar 2003 11:00:42 -0500

 On Thu, Mar 27, 2003 at 03:38:35PM -0000, mat at lcs dot mit dot edu wrote:
 > I have a large, multithreaded program that doesn't work on gdb-5.3.
 > I am running RedHat Linux 8.0 using glibc-2.3.2 (RedHat's official rpm
 > upgrade) with all upgrade RPMs applied.
 
 Wait wait... a glibc 2.3.2 upgrade for Red Hat 8.0?  I don't know much
 about Red Hat, and I didn't know there was such an upgrade, but I bet
 this new upgrade has NPTL support (new replacement threads library). 
 Do you know or can you find out?  Anyone else know?
 
 If so it is not surprising that GDB doesn't work.  You'll have to get a
 patched GDB from Red Hat for now until NPTL support is available.
 
 
 > [The "handle SIG32 noprint" I typed isn't important, it just silences
 >  a few SIG32 messages (I think that's the signal used by pthreads; and
 >  gdb too?)  Without it, it stops a few times on SIG32 before failing
 >  in the same way.  At least, it usually does; exactly when it fails
 >  changes sometimes if I have to type "cont", perhaps suggesting a race
 >  condition.  Perhaps the SIG32 message is very significant; are other
 >  pthreads users told about this?  It's very annoying.]
 
 You should never see a SIG32 message.  If you do, then probably thread
 debugging is broken.
 
 > BUG2: gdb SEGVs during "info threads"
 > 
 > gdb crashes because 'selected_frame' is NULL, a case that this code
 > in 'info_threads_command' really isn't expecting:
 > 
 >   cur_frame = find_relative_frame (selected_frame, &counter);
 > 
 > I don't know what the right fix is, but it seems to me that either:
 > 
 >    1) 'info_threads_command' should check for a NULL selected_frame
 >       and print out a message about "no stack" or somesuch, or
 >       some kind of warning; or
 > 
 >    2) if some invariant was broken elsewhere that 'info_threads_command'
 >       shouldn't have to worry about, that code needs to be changed
 >       to preserve the invariant.  'selected_frame' being NULL is no
 >       doubt caused by the EPERM from ptrace described above.  But a
 >       failed call to 'ptrace' should not be able to make gdb SEGV.
 
 I -think- something's already gone wrong if selected_frame is NULL
 here, but probably this should be get_selected_frame ()... does that
 help with the segfault?
 
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer