From Bugzilla Helper: User-Agent: Opera/7.11 (Linux 2.4.20-9 i686; U) [en] Description of problem: Stepping through this program with gdb causes a SIGSEGV. This program runs fine otherwise. Memory debuggers like Electric Fence and valgrind give it a clean bill of health, but under gdb it crashes. I will attach the program shortly. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Compile program without optimization: "g++ foo.cc -g -o foo" 2. Invoke gdb on foo and set breakpoint at line 46 (d->HandleEvent(d)) 3. Step until SIGSEGV happens. Actual Results: Here is the transcript: $ g++ foo.cc -g -o foo $ gdb foo GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 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 "i386-redhat-linux-gnu"... (gdb) break foo.cc:46 Breakpoint 1 at 0x80488d0: file foo.cc, line 46. (gdb) r Starting program: /home/chris/foo Breakpoint 1, main () at foo.cc:46 46 d->HandleEvent(d); (gdb) s XEventBroker::HandleEvent(XObjectEventListener*) (this=0x8049ee0, listener=0x8049ee4) at foo.cc:30 30 listener->ProcessEvent(); (gdb) s XObjectEventListener::ProcessEvent() (this=0x8049ee4) at foo.cc:35 35 ProcessMessage(); (gdb) s Program received signal SIGSEGV, Segmentation fault. 0x0804897a in non-virtual thunk to Derived::ProcessMessage() () at streambuf:131 131 char_type _M_pback[_S_pback_size]; (gdb) bt #0 0x0804897a in non-virtual thunk to Derived::ProcessMessage() () at streambuf:131 #1 0x0804880a in XObjectEventListener::ProcessEvent() (this=0x8049ee0) at foo.cc:35 #2 0x080487ed in XEventBroker::HandleEvent(XObjectEventListener*) ( this=0x8049ee0, listener=0x8049ee4) at foo.cc:30 #3 0x08048900 in main () at foo.cc:46 #4 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 Expected Results: The program should have run to completion without error. Additional info:
Created attachment 91676 [details] Program that crashes under GDB
Created attachment 91677 [details] Program that crashes under GDB
Created attachment 91739 [details] readelf -wl for program The readelf linetable data refers to 0x804897c. This address is 2 bytes into the first instruction of the Derived::ProcessMessage thunk. Gdb picks this up and ends up placing a breakpoint at that position which causes the SIGSEGV to occur (we are tampering with the address used in an addl insn rather than replacing the insn). The line also is noted as coming from streambuf. Test does not fail when compiled with older compiler using -gdwarf-2 option.
A problem has been noted in the line table info created by the compiler. An invalid address in the line table info is picked up by gdb and used later for inserting a breakpoint. The insertion modifies an address used in the program's insn, rather than replacing the insn itself, and thus causes the SIGSEGV. Problem does not exist on older compiler (2.96) generating dwarf2 debug info.
This is clearly assembler thing, GCC only writes .loc directives.
It is even fixed in CVS binutils (and rawhide as well). http://sources.redhat.com/ml/binutils/2003-07/msg00294.html