I believe that there is a problem in the way that gdb collects section
information for a process that it attaches to. Here's a scenario that will
reliably cause gdb to seg fault for me:
1. Run a program that doesn't immediately return:
$ cat foo.c
#include <stdio.h>
int main(void)
{
char buf[256];
printf("Hello, world..."); fflush(stdout);
fgets(buf, sizeof(buf), stdin);
return buf[0];
}
$ cc -g foo.c -o foo
$ foo
Hello, world...
2. Attach to it:
$ gdb foo <pid>
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
/home/dmm/Work/gdbprob/9518: No such file or directory.
Attaching to program: /home/dmm/Work/gdbprob/foo, process 9518
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
0x400c84c4 in __libc_read () from /lib/libc.so.6
(gdb)
3. Execute "info files":
(gdb) info files
Symbols from "/home/dmm/Work/gdbprob/foo".
Unix child process:
Using the running image of attached process 9518.
While running this, GDB does not access memory from...
Local exec file:
`/home/dmm/Work/gdbprob/foo', file type elf32-i386.
Entry point: 0x80483d0
Segmentation fault
The trap occurs in print_section_info; the problem is that the section_table
element of the target_ops parameter contains garbage. It appears to me
that the section table built in exec_file_attach somehow gets returned to
the free pool, even though there are other data structures that expect it
to stick around.
I've reproduced this with the gdb 4.18 RPMs from SuSE and RedHat, as well as
a freshly built version from the original source on sourceware.cygnus.com.
Fwiw, I'm compiling using egcs 2.91.66 on Linux kernel 2.2.12-20.
Can anybody else reproduce this problem and hopefully suggest a fix for it?
dave
--
David Mooney | pez at vex dot net | "What! No beans?"
