I've got gdb-5.1-3. It's coredumped on me several times since I upgraded to it. Here's a stack trace from the most recent one: #0 0x40114e1c in memcpy () from /lib/i686/libc.so.6 #1 0x00000003 in ?? () #2 0x080bb05d in do_xfer_memory () #3 0x080bb1d5 in target_xfer_memory () #4 0x080bafc7 in target_read_memory () #5 0x08080482 in partial_memory_read () #6 0x08080855 in val_print_string () #7 0x080d0bec in c_val_print () #8 0x0807f920 in val_print () #9 0x08083737 in print_frame_args () #10 0x080996d3 in print_args_stub () #11 0x080d5909 in catch_errors () #12 0x08099d5b in print_frame () #13 0x080997a3 in print_frame_info_base () #14 0x080994c8 in show_and_print_stack_frame_stub () #15 0x080d5909 in catch_errors () #16 0x080995f2 in show_and_print_stack_frame () #17 0x08095dcd in normal_stop () #18 0x08090dc3 in step_1 () #19 0x08090be1 in step_command () #20 0x080d5c76 in execute_command () #21 0x0809d5c3 in command_handler () #22 0x0809da01 in command_line_handler () #23 0x08191775 in rl_callback_read_char () #24 0x0809d4ba in stdin_event_handler () #25 0x080f029e in handle_file_event () #26 0x080efd67 in process_event () #27 0x080efdc8 in gdb_do_one_event () #28 0x080d5909 in catch_errors () #29 0x080efe04 in start_event_loop () #30 0x0806f1e2 in captured_command_loop () #31 0x080d5909 in catch_errors () #32 0x0806fb54 in captured_main () #33 0x080d5909 in catch_errors () #34 0x0806fc58 in main () #35 0x400a86e7 in __libc_start_main (main=0x806fc20 <main>, argc=3, ubp_av=0xbffffa14, init=0x806e620 <_init>, fini=0x81a49e8 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffa0c) at ../sysdeps/generic/libc-start.c:129 Let me know if it would be useful for me to recompile gdb with debugging symbols and see if it happens again.
Can you reproduce it? What's the rest of your system, like glibc, kernel, compiler etc? I've yet to see it coredump...
Not repeatable on demand, but it happens pretty regularly. Downgrading to 5.2-2 seems to have made the problem go away, so perhaps 5.1-3 was compiled with a version of gcc which has problems (I know that bug reports from me yesterday prompted Jakub to fix at least two different gcc bugs :-). Also, I noticed that when my program is compiled with "-g -O2", gdb frequently gets arguments and such wrong when displaying the arguments to a function call. This problem goes away if I get rid of the "-O2". I know that optimization frequently confuses gdb; I'm just mentioning this in case it's not expected behavior.
As for what I'm running, I've got current everything from Rawhide, except I'm using glibc-2.2.4 instead of glibc-2.2.90 until 2.2.90 is recompiled with a gcc fix that Jakub made yesterday that's affecting me.
Keeping it open until things have stabilized... either it works, or it isn't reproducible, and will be closed anyway.
It's easy to reproduce here: int main() { char *foo = "foo"; return 0; } Set a breakpoint a main, run, and print foo => SIGSEGV with a backtrace much like above. System: rawhide as of today: gdb-5.1-3 gcc-3.1-0.18 glibc-2.2.90-3 kernel-2.4.17-0.2
Rebuilding with gcc 2.96 seems to fix the problem.
The test programor gdb? (the former would result in a different debug format)
Rebuilding gdb.
Reclassifying as a gcc bug.
(BTW, if you're using rawhide gcc, use the latest one and check if that fixes it)
Trond, what makes you think it is a gcc bug? The important thing is that rawhide gcc uses dwarf-2 by default while before gcc used stabs by default. So if I could guess, I'd say it is a dwarf2 reader bug.
The problem seems to have disappeared in rawhide version of gdb (5.1.1-1). So probably a bug in gdb 5.1 triggered by the new gcc.
Jakub: Because the reporter said rebuilding gdb (not the test program) with gcc 2.96RH fixed the problem. Anyway, it seems to be fixed now (the "new" gdb didn't contain code fixes I didn't already have) after rebuilding with a more current toolchain.