Bug 90846 - Stepping w/ GDB causes C++ program to crash
Stepping w/ GDB causes C++ program to crash
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: binutils (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-14 12:53 EDT by Christopher Wong
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
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 15:56:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Program that crashes under GDB (778 bytes, text/plain)
2003-05-14 12:54 EDT, Christopher Wong
no flags Details
Program that crashes under GDB (778 bytes, text/plain)
2003-05-14 12:54 EDT, Christopher Wong
no flags Details
readelf -wl for program (11.84 KB, text/plain)
2003-05-16 14:34 EDT, Jeff Johnston
no flags Details

  None (edit)
Description Christopher Wong 2003-05-14 12:53:36 EDT
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 12:54:39 EDT
Created attachment 91676 [details]
Program that crashes under GDB
Comment 2 Christopher Wong 2003-05-14 12:54:41 EDT
Created attachment 91677 [details]
Program that crashes under GDB
Comment 3 Jeff Johnston 2003-05-16 14:34:30 EDT
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 14:39:30 EDT
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 15:13:06 EDT
This is clearly assembler thing, GCC only writes .loc directives.
Comment 6 Jakub Jelinek 2003-08-01 15:56:29 EDT
It is even fixed in CVS binutils (and rawhide as well).
http://sources.redhat.com/ml/binutils/2003-07/msg00294.html

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