Subject: Re: forwarded message from Chet Ramey (Re: bash-1.14.5 crashes)
To: None <jconklin@netcom.com>
From: None <Havard.Eidnes@runit.sintef.no>
List: current-users
Date: 09/17/1995 16:31:27
> > > Program terminated with signal 10, Bus error.
> > > #0 0x5d168 in _catclose ()
> > > (gdb) bt
> > > #0 0x5d168 in _catclose ()
> > > #1 0x5cc00 in _catopen ()
> > > #2 0x5c640 in __strerror ()
> > > #3 0x58d50 in strerror ()
>
> I don't think we can trust this stacktrace. _catopen() doesn't call
> _catclose(). I beleive that strerror handles error conditions (errno
> out of range / bad message catalog / missing message catalog / etc)
> correctly. Perhaps things are screwed up already? ie. why would a
> cd be calling strerror in the first place?
I think that what is happening here is that the picture is being
distorted by the fact that there are a few static functions in
this picture as well, and as such those symbols are not available
to gdb, so it picks the "closest" function to display in the
stack trace. If you do as I and recompile the NLS part of the
library with debug symbols, you will get a better picture.
See my last message concerning what the bug really is in this
case.
- H=E5vard