Re: Weird segfault with library
First of all, do you mean bash 2.02? There is no 2.2 that I see...
On Sun, Nov 08, 1998 at 03:51:57PM -0800, Guy Maor wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
>
> > Hmm, can you gdb this and show a stack trace?
>
> Oops, I forgot to post that. (I recompiled the old bash with symbols.)
> It's not terribly enlightening.
>
> (gdb) where
> #0 0x0 in ?? ()
> #1 0x8068737 in find_user_command_in_path (name=0xbffffd76 "bash",
> path_list=0x80b508c "/home/maor/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:
> /usr/local/bin", flags=36) at execute_cmd.c:4400
> #2 0x8067e51 in _find_user_command_internal (name=0xbffffd76 "bash", flags=36)
> at execute_cmd.c:4070
<snip>
> (gdb) up
> #1 0x8068737 in find_user_command_in_path (name=0xbffffd76 "bash",
> path_list=0x80b508c "/home/maor/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/usr/local/bin", flags=36) at execute_cmd.c:4400
> 4400 stat (".", &dotinfo);
> (gdb) p dotinfo
> $2 = {st_dev = 18446744073709551615, __pad1 = 65535, st_ino = 4294967295,
> st_mode = 4294967295, st_nlink = 4294967295, st_uid = 1073786568,
> st_gid = 0, st_rdev = 6568, __pad2 = 64152, st_size = 134736623,
> st_blksize = 134974252, st_blocks = 134885653, st_atime = 49,
> __unused1 = 134974284, st_mtime = -1073743188, __unused2 = 134652531,
> st_ctime = 134885653, __unused3 = 134966828, __unused4 = 134974284,
> __unused5 = 3221224132}
OK, so it died before filling out the stat struct.
> Interestingly, running it from the command line produces different
> results:
Um, how did you run it in the first (above) case?
> readline version 2.2-bash
> (gdb) run
> Starting program: /bin/bash
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0 in ?? ()
> (gdb) where
> #0 0x0 in ?? ()
> #1 0x809399c in _evalfile (filename=0x80bbe0c "/home/maor/.bashrc", flags=9)
> at evalfile.c:82
<snip>
> (gdb) up
> #1 0x809399c in _evalfile (filename=0x80bbe0c "/home/maor/.bashrc", flags=9)
> at evalfile.c:82
> 82 if (fd < 0 || (fstat (fd, &finfo) == -1))
> (gdb) p fd
> $1 = 5
> (gdb) p finfo
> $2 = {st_dev = 18446744073709551615, __pad1 = 65535, st_ino = 4294967295,
> st_mode = 4294967295, st_nlink = 4294967295, st_uid = 4294967295,
> st_gid = 4294967295, st_rdev = 18446744073709551615, __pad2 = 65535,
> st_size = -1, st_blksize = 4294967295, st_blocks = 4294967295,
> st_atime = -1, __unused1 = 4294967295, st_mtime = -1,
> __unused2 = 4294967295, st_ctime = -1, __unused3 = 4294967295,
> __unused4 = 3221224324, __unused5 = 134877351}
> (gdb)
>
> So it does consistently crash inside a stat or fstat call.
OK. As I recall bash includes in libreadline an implementation of
stat, for some reason - I was never able to track down how this
occured. My guess is that the cause of the crash has to do with this.
stat's structures change periodically, and so glibc uses a clever
mechanism (xstat IIRC) to track the changes. I would suspect that
libreadline's stat (why it is there is unclear) is of a different
version than glibc's and thus the new libreadline's (or perhaps the new
libreadline just passes it on to glibc).
Dan
Reply to: