More with Mozilla and glibc
hcaley at loomer.com
Sat Sep 11 15:13:35 EST 1999
Wow. Well, I'm still thinking that my Mozilla problem is glibc related, even if
the gdb output is bogus ; ). I know that Mozilla isn't even alpha yet, but other
people have better luck than I do, and they are using older libraries than I am.
I just don't want do deal with downgrading glibc just to test that (although I
have tried downgrading gcc, but I got the same problems).
Thanks for the info!
Kevin Hendricks wrote:
> I get this same error trying to debug the native threads version of the jdk. I
> don't think the problem is in glibc at all.
> The problem is in 4.17 versions of gdb under glibc 2.1. In fact gdb can't
> handle the realtime signals yet and so it stops when it receives one.
> Therefore the error message in no way indicates the actual seg-fault or bug you
> are trying to find and fix.
> I think gdb simply has no maintainer yet (Kevin Buettner will be keeping it
> up, if he hasn't started already) and no one has updated it to reflect all of
> the new realtime signals now available in glibc 2.1. The error message you get
> just prevents me from using gdb 4.17 when debugging any native threads
> (libpthread code). Once the new thread signals numbers are included, you
> should be able to use the handle nostop command in gdb to prevent the
> libpthread signals from disrupting your debugging.
> The only workaround I know of is to rebuild linuxthreads (part of glibc) and
> manually turn off the use of the new realtime signals and instead use the old
> SIGUSR1 and SIGUSR2 signals for libpthreads until gdb gets fixed.
> I hope this helps.
Hugh Caley, Unix Administrator
Babcock & Brown, San Francisco
hughc at babcockbrown.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev