Bug 58390 - gdb is coredumping
gdb is coredumping
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-15 12:01 EST by Jonathan Kamens
Modified: 2007-04-18 12:39 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-28 09:06:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2002-01-15 12:01:45 EST
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.
Comment 1 Trond Eivind Glomsrxd 2002-01-15 12:03:52 EST
Can you reproduce it? What's the rest of your system, like glibc, kernel,
compiler etc? I've yet to see it coredump...
Comment 2 Jonathan Kamens 2002-01-15 12:55:42 EST
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.
Comment 3 Jonathan Kamens 2002-01-15 12:56:30 EST
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.
Comment 4 Trond Eivind Glomsrxd 2002-01-17 15:13:28 EST
Keeping it open until things have stabilized... either it works, or it isn't
reproducible, and will be closed anyway.
Comment 5 Stefan Sorensen 2002-01-20 08:36:55 EST
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
Comment 6 Stefan Sorensen 2002-01-20 16:27:07 EST
Rebuilding with gcc 2.96 seems to fix the problem.
Comment 7 Trond Eivind Glomsrxd 2002-01-21 12:16:07 EST
The test programor gdb? (the former would result in a different debug format)
Comment 8 Stefan Sorensen 2002-01-21 12:19:12 EST
Rebuilding gdb.
Comment 9 Trond Eivind Glomsrxd 2002-01-21 12:20:45 EST
Reclassifying as a gcc bug.
Comment 10 Trond Eivind Glomsrxd 2002-01-21 12:21:24 EST
(BTW, if you're using rawhide gcc, use the latest one and check if that fixes it)
Comment 11 Jakub Jelinek 2002-01-28 08:49:25 EST
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.
Comment 12 Stefan Sorensen 2002-01-28 09:06:17 EST
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.
Comment 13 Trond Eivind Glomsrxd 2002-01-28 10:42:03 EST
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.

Note You need to log in before you can comment on or make changes to this bug.