I tried to add a breakpoint at function entry. Oddly, gdb believed that the breakpoint didn't exist, asking if it should be added pending shared library load. I replied yes and started running the program. When it hit the breakpoint it core dumped. Exact version: Fedora (6.8-29.fc10) The binary I was debugging is available here: http://valhenson.org/patches/automount Exact commands to trigger bug: set args -dfv break become_daemon (answer y) run
Subject: Re: New: gdb core dumps on adding a breakpoint On Friday 09 January 2009 17:55:37, vaurora at redhat dot com wrote: > I tried to add a breakpoint at function entry. Oddly, gdb believed that the > breakpoint didn't exist, asking if it should be added pending shared library > load. I replied yes and started running the program. When it hit the > breakpoint it core dumped. > > Exact version: Fedora (6.8-29.fc10) Is this happening with FSF gdb as well, or just in redhat's custom gdb? If yes, then could you try it with mainline please to check if it has already been fixed?
I can't get the gdb-6.8.50.20090109 snapshot to compile: [val@clunky gdb-6.8.50.20090109]$ ./configure --prefix=/usr/local [val@clunky gdb-6.8.50.20090109]$ make [...] gcc -g -O2 -I. -I.././gdb -I.././gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I.././gdb/../include/opcode -I.././gdb/../readline/.. -I../bfd -I.././gdb/../bfd -I.././gdb/../include -I../libdecnumber -I.././gdb/../libdecnumber -I.././gdb/gnulib -Ignulib -DMI_OUT=1 -DTUI=1 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -o coff-pe-read.o -MT coff-pe-read.o -MMD -MP -MF .deps/coff-pe-read.Tpo coff-pe-read.c coff-pe-read.c: In function ‘read_pe_exported_syms’: coff-pe-read.c:226: error: expected ‘)’ before ‘;’ token coff-pe-read.c:358: error: expected ‘;’ before ‘}’ token If you can install the Fedora gdb rpm, you ought to have all the data necessary to reproduce it - core file and exact command sequence are included in the original report.
Subject: Re: gdb core dumps on adding a breakpoint On Friday 09 January 2009 20:00:30, vaurora at redhat dot com wrote: > > ------- Additional Comments From vaurora at redhat dot com 2009-01-09 20:00 ------- > I can't get the gdb-6.8.50.20090109 snapshot to compile: > > [val@clunky gdb-6.8.50.20090109]$ ./configure --prefix=/usr/local > [val@clunky gdb-6.8.50.20090109]$ make > [...] > gcc -g -O2 -I. -I.././gdb -I.././gdb/config > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > -I.././gdb/../include/opcode -I.././gdb/../readline/.. -I../bfd > -I.././gdb/../bfd -I.././gdb/../include -I../libdecnumber > -I.././gdb/../libdecnumber -I.././gdb/gnulib -Ignulib -DMI_OUT=1 -DTUI=1 > -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral > -Wno-pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -o > coff-pe-read.o -MT coff-pe-read.o -MMD -MP -MF .deps/coff-pe-read.Tpo coff-pe-read.c > coff-pe-read.c: In function ‘read_pe_exported_syms’: > coff-pe-read.c:226: error: expected ‘)’ before ‘;’ token > coff-pe-read.c:358: error: expected ‘;’ before ‘}’ token > Oh, chucks, that made it to the last snapshot. Build errors are rare though. That's been fixed in mainline already. You could try the version before that one, or wait for a new snapshot, or just try vanilla gdb 6.8. > If you can install the Fedora gdb rpm, you ought to have all the data necessary > to reproduce it - core file and exact command sequence are included in the > original report. Right, but I also know that your employer has a several local changes in their tree, over which we're not responsible for. If you can help with the triage, it makes it much easier, and the end result being that you get a fixed gdb faster.
Subject: Re: gdb core dumps on adding a breakpoint FWI, I've just tried this on: - gdb 6.8-debian: Got it to crash as: (gdb) set args -dfv (gdb) break become_daemon Function "become_daemon" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (become_daemon) pending. (gdb) run Starting program: /home/pedro/downloads/automount -dfv Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f6cfc0066e0 (LWP 30766)] 0x00000000004a7d4d in disable_breakpoints_at_startup () (gdb) bt #0 0x00000000004a7d4d in disable_breakpoints_at_startup () #1 0x00000000004dce6f in post_create_inferior () #2 0x00000000004dd274 in ?? () #3 0x000000000044d7e2 in execute_command () #4 0x00000000004ee04b in ?? () #5 0x00000000004eecdb in ?? () #6 0x00007f6cfbbf6ea7 in rl_callback_read_char () from /lib/libreadline.so.5 #7 0x00000000004ee229 in ?? () #8 0x00000000004eccd3 in ?? () #9 0x00000000004ed5e8 in gdb_do_one_event () #10 0x00000000004ea4ab in catch_errors () #11 0x0000000000493876 in ?? () #12 0x0000000000445dc9 in ?? () #13 0x00000000004ea4ab in catch_errors () #14 0x0000000000446566 in ?? () #15 0x00000000004ea4ab in catch_errors () #16 0x0000000000445db4 in gdb_main () #17 0x0000000000445d86 in main () Now, disable_breakpoints_at_startup isn't a function that's in mainline. This is part of a series that adds support for PIE. I know that there are two different implementations that add PIE support for GDB, one from redhat, and one from suse. Maybe debian has the redhat version, and I'm triggering the same bug you are. - vanilla FSF gdb 6.8 (gdb) run Starting program: /home/pedro/downloads/automount -dfv /home/pedro/downloads/automount: this program must be run by root. Program exited with code 01. (gdb) Ok, so ... > sudo gdb ... (gdb) set args -dfv (gdb) break become_daemon Function "become_daemon" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (become_daemon) pending. (gdb) run Starting program: /home/pedro/downloads/automount -dfv /home/pedro/downloads/automount: test mount forbidden or incorrect kernel protocol version, kernel protocol version 5.00 or above required. Program exited with code 01. (gdb) - mainline: behaved the same as FSF 6.8. I've done my best to try to reproduce this. Can you please confirm if this happens to you with an FSF gdb? If so, please provide a backtrace. Ideally, we'd get a smaller testcase, as I'm not sure I'm seeing what you're seeing. I'm reserving the right to close this as invalid if I don't hear back in a week or so. ;-)
Subject: Re: gdb core dumps on adding a breakpoint On Monday 12 January 2009 19:26:38, pedro at codesourcery dot com wrote: > - gdb 6.8-debian: For the record, this was ubuntu 8.04's gdb on x86_64. It seems that ubuntu people install a bunch of additional patches on top of debian's, and forget to change the version string.
I retried with this version: GNU gdb (GDB) 6.8.50.20090108 It does not core dump, hurray! But I'm still having trouble with breakpoints. For example: [val@clunky src]$ sudo /usr/local/bin/gdb ./automount GNU gdb (GDB) 6.8.50.20090108 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... (gdb) break main Breakpoint 1 at 0x8a90: file automount.c, line 1799. (gdb) run Starting program: /home/val/src/automount Error in re-setting breakpoint 1: Cannot access memory at address 0x8a90 Error in re-setting breakpoint 1: Cannot access memory at address 0x8a90 /home/val/src/automount: program is already running. Program exited normally. (gdb) (Ignore the "program is already running" line - it is output from automount itself and is not correct since it's the bug I was debugging.) On to the original breakpoint, that doesn't behave correctly either: [restart gdb] (gdb) break become_daemon Function "become_daemon" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (become_daemon) pending. (gdb) run Starting program: /home/val/src/automount /home/val/src/automount: program is already running. Program exited normally. (gdb) First, become_daemon() is not part of a shared library. Second, the breakpoint isn't triggering - the "program is already running" check is part of the become_daemon() function.
Yes, this is a typical error when you try to use GDB on a PIE binary. GDB doesn't support PIEs; the Ubuntu patch which caused your core dump purports to add PIE support (but has some issues, I guess).
Indeed: >file downloads/automount downloads/automount: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped There's PR 9174, which is exactly about the fact that we don't support PIE yet. Valerie, your best bets are to either report the crash bug with Red Hat's gdb to Red Hat, or, relink your app as a normal executable, to be able to use FSF gdb on it. Thanks! *** This bug has been marked as a duplicate of 9174 ***
So I don't consider myself a beginning computer user and this still feels like a bug to me. Forget the crash in vendor-specific code; with vanilla gdb I set a breakpoint, it appears to succeed, and then, well, it just doesn't work. Until such time as PIE support is merged, perhaps gdb could print some sort of informational message or fail the breakpoint or give some indication that the expected behavior is that the breakpoint will not be triggered. It would at least cut down on the number of duplicate bugs filed.
FYI, I'd like to have such warning implemented before we release 7.0, so I plan to work on this in the next few weeks. Or we can get lucky and someone will push one of the two current patches floating around which add support for PIE binaries.
Assigning bug to myself. Just posted first stab at fixing it to gdb-patches@: http://sourceware.org/ml/gdb-patches/2009-07/msg00664.html
This bug was just resolved by the following commit: http://sourceware.org/ml/gdb-cvs/2009-08/msg00014.html A warning message is now shown when GDB detects that it's dealing with a PIE binary. See bug #9174 for status on proper support for PIE binaries.