Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 90846

Summary: Stepping w/ GDB causes C++ program to crash
Product: [Retired] Red Hat Linux Reporter: Christopher Wong <chris>
Component: binutilsAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 2.14.90.0.5-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-01 19:56:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Program that crashes under GDB
none
Program that crashes under GDB
none
readelf -wl for program none

Description Christopher Wong 2003-05-14 16:53:36 UTC
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:

Comment 1 Christopher Wong 2003-05-14 16:54:39 UTC
Created attachment 91676 [details]
Program that crashes under GDB

Comment 2 Christopher Wong 2003-05-14 16:54:41 UTC
Created attachment 91677 [details]
Program that crashes under GDB

Comment 3 Jeff Johnston 2003-05-16 18:34:30 UTC
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.

Comment 4 Jeff Johnston 2003-05-16 18:39:30 UTC
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.

Comment 5 Jakub Jelinek 2003-08-01 19:13:06 UTC
This is clearly assembler thing, GCC only writes .loc directives.

Comment 6 Jakub Jelinek 2003-08-01 19:56:29 UTC
It is even fixed in CVS binutils (and rawhide as well).
http://sources.redhat.com/ml/binutils/2003-07/msg00294.html