This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

possible gdb bug?


Hello gdb list,

I'm not a subscriber to this list, and the following message originated not here, but on the Insight mailing list.  I had been working with that list (and Keith Seitz in particular) to try to solve the problems I was having with Insight(and gdb by extension) built on cygwin.

The backstory is that I built an Insight snapshot (20030621) on my Cygwin box, but found that gdb crashed when trying to debug a trivial target program.  I also found that my Cygwin installation had a working gdb.  So, I rebuilt my snapshot with debugging info and no optimization, which lead to the following message.  Keith has suggested that this points up a recently introduced bug in the dwarf2 readers.  If this problem has been fixed in recent snapshots, please let me know.  If I can provide more information, again, please let me know.

-----Original Message-----
From: Kevin Powell 
Sent: Monday, June 23, 2003 6:46 PM
Subject: RE: Building Insight snapshot on CygWin?


Keith,

As promised, here is the result of using an unoptimized insight/gdb.  BTW, thanks for the tip on turning off the optimizations.  At least now I can get a usable (not to me, but maybe to others) backtrace.

The executive summary is that the unoptimized gdb behaves a bit better than my first attempt.  At least now I can set a breakpoint and run to it. However, the first time I try to step, gdb crashes with the same segfault as before.  And, to answer your question from the last email, it really is gdb that is crashing -- the target program runs fine both under the distributed gdb and outside of the debugger.  And, now I know the reason why it crashes:  

gdb/dwarf2-frame.c:508 fs->data_align = fde->cie->data_alignment_factor;

it turns out that fde->cie is NULL.  Why this might happen requires, I think, some knowledge of how gdb internals work, and I have no such knowledge.
 
The following text captures my attempt to run my broken gdb inside of the working distributed gdb.

$ /usr/bin/gdb /usr/local/bin/gdb
GNU gdb 2003-03-03-cvs (cygwin-special)
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 "i686-pc-cygwin"...
(gdb) run
Starting program: /usr/local/bin/gdb.exe
GNU gdb 20030621
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 "i686-pc-cygwin".
(gdb) file HelloWorld.exe
Reading symbols from HelloWorld.exe...done.
(gdb) break main
Breakpoint 1 at 0x4010bc: file HelloWorld.c, line 5.
(gdb) run
Starting program: /home/Administrator/testing/HelloWorld.exe

Breakpoint 1, main (argc=1, argv=0xa042a68) at HelloWorld.c:5
5               printf ("Hello World!\n");
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x0057f581 in dwarf2_frame_cache (next_frame=0x101231b8, this_cache=0x10123224)
at ../../insight+dejagnu-20030621/gdb/dwarf2-frame.c:508
508       fs->data_align = fde->cie->data_alignment_factor;
(gdb) bt
#0  0x0057f581 in dwarf2_frame_cache (next_frame=0x101231b8, this_cache=0x10123224) at ../../insight+dejagnu-20030621/gdb/dwarf2-frame.c:508
#1  0x0057f980 in dwarf2_frame_this_id (next_frame=0x101231b8, this_cache=0x10123224, this_id=0x10123240) at ../../insight+dejagnu-20030621/gdb/dwarf2-frame.c:599
#2  0x00464398 in get_frame_id (fi=0x10123210) at ../../insight+dejagnu-20030621/gdb/frame.c:243
#3  0x0043a1d6 in step_1 (skip_subroutines=1, single_inst=0, count_string=0x0) at ../../insight+dejagnu-20030621/gdb/infcmd.c:631
#4  0x00439f7b in next_command (count_string=0x0, from_tty=1) at ../../insight+dejagnu-20030621/gdb/infcmd.c:559
#5  0x00405a9b in do_cfunc (c=0x1010e130, args=0x0, from_tty=1) at ../../insight+dejagnu-20030621/gdb/cli/cli-decode.c:53
#6  0x00408157 in cmd_func (cmd=0x1010e130, args=0x0, from_tty=1) at ../../insight+dejagnu-20030621/gdb/cli/cli-decode.c:1517
#7  0x00424d8a in execute_command (p=0x10102ce9 "", from_tty=1) at ../../insight+dejagnu-20030621/gdb/top.c:716
#8  0x0048bd6a in command_handler (command=0x10102ce8 "n") at ../../insight+dejagnu-20030621/gdb/event-top.c:500
#9  0x0048c58b in command_line_handler (rl=0x1011c8e8 "D{\023\020") at ../../insight+dejagnu-20030621/gdb/event-top.c:793
#10 0x00601680 in rl_callback_read_char () at ../../insight+dejagnu-20030621/readline/callback.c:123
#11 0x0048b3ab in rl_callback_read_char_wrapper (client_data=0x0) at ../../insight+dejagnu-20030621/gdb/event-top.c:166
#12 0x0048bb97 in stdin_event_handler (error=0, client_data=0x0) at ../../insight+dejagnu-20030621/gdb/event-top.c:416
#13 0x004a75ab in handle_file_event (event_file_desc=0) at ../../insight+dejagnu-20030621/gdb/event-loop.c:721
#14 0x004a6d95 in process_event () at ../../insight+dejagnu-20030621/gdb/event-loop.c:334
#15 0x004a6dde in gdb_do_one_event (data=0x0) at ../../insight+dejagnu-20030621/gdb/event-loop.c:371
#16 0x004248be in do_catch_errors (uiout=0x10125708, data=0x22f868) at ../../insight+dejagnu-20030621/gdb/top.c:497
#17 0x004246be in catcher (func=0x4248a2 <do_catch_errors>, func_uiout=0x10125708, func_args=0x22f868, func_val=0x22f874, func_caught=0x22f870, errstring=0x4a6df7 "", mask=6) at ../../insight+dejagnu-20030621/gdb/top.c:429
#18 0x0042490a in catch_errors (func=0x4a6daa <gdb_do_one_event>, func_args=0x0, errstring=0x4a6df7 "", mask=6) at ../../insight+dejagnu-20030621/gdb/top.c:509
#19 0x004a6e23 in start_event_loop () at ../../insight+dejagnu-20030621/gdb/event-loop.c:397
#20 0x0048b4b9 in cli_command_loop () at ../../insight+dejagnu-20030621/gdb/event-top.c:198
#21 0x004428cd in current_interp_command_loop () at ../../insight+dejagnu-20030621/gdb/interps.c:279
#22 0x0040110b in captured_command_loop (data=0x0) at ../../insight+dejagnu-20030621/gdb/main.c:97
#23 0x004248be in do_catch_errors (uiout=0x10125708, data=0x22fa58) at ../../insight+dejagnu-20030621/gdb/top.c:497
#24 0x004246be in catcher (func=0x4248a2 <do_catch_errors>, func_uiout=0x10125708, func_args=0x22fa58, func_val=0x22fa64, func_caught=0x22fa60, errstring=0x401260 "", mask=6) at ../../insight+dejagnu-20030621/gdb/top.c:429
#25 0x0042490a in catch_errors (func=0x401100 <captured_command_loop>, func_args=0x0, errstring=0x401260 "", mask=6) at ../../insight+dejagnu-20030621/gdb/top.c:509
#26 0x0040263d in captured_main (data=0x22fd98) at ../../insight+dejagnu-20030621/gdb/main.c:811
#27 0x004248be in do_catch_errors (uiout=0x677420, data=0x22fd38) at ../../insight+dejagnu-20030621/gdb/top.c:497
#28 0x004246be in catcher (func=0x4248a2 <do_catch_errors>, func_uiout=0x677420, func_args=0x22fd38, func_val=0x22fd44, func_caught=0x22fd40, errstring=0x401260 "", mask=6) at ../../insight+dejagnu-20030621/gdb/top.c:429
#29 0x0042490a in catch_errors (func=0x4014be <captured_main>, func_args=0x22fd98, errstring=0x401260 "", mask=6) at ../../insight+dejagnu-20030621/gdb/top.c:509
#30 0x00402674 in gdb_main (args=0x22fd98) at ../../insight+dejagnu-20030621/gdb/main.c:820
#31 0x004010f6 in main (argc=1, argv=0x10102a68) at ../../insight+dejagnu-20030621/gdb/gdb.c:35
(gdb)

And in the next gdb session (since I forgot to do this on the first run:)

(gdb) info args
next_frame = (struct frame_info *) 0x101231b8
this_cache = (void **) 0x10123224
(gdb) info locals
old_chain = (struct cleanup *) 0x1011c778
num_regs = 40
cache = (struct dwarf2_frame_cache *) 0x101232b8
fs = (struct dwarf2_frame_state *) 0x102056e0
fde = (struct dwarf2_fde *) 0x10151db8
reg = 6
(gdb) p fde->cie
$1 = (struct dwarf2_cie *) 0x0
(gdb)

Kevin Powell

-----Original Message-----
From: Keith Seitz
Sent: Monday, June 23, 2003 6:18 PM
To: Kevin Powell
Cc: insight@sources.redhat.com
Subject: RE: Building Insight snapshot on CygWin?


On Mon, 2003-06-23 at 17:14, Kevin Powell wrote:
> Starting program: /home/Administrator/testing/HelloWorld.exe
>      58 [main] gdb 2348 handle_exceptions: Error while dumping state (probably corrupted stack)
> Segmentation fault (core dumped)

Yeah, that doesn't look promising, eh? ;-)

One quick question: did you really do this with "gdb HelloWorld.exe"? In
other words, gdb itself crashes trying to debug this?

> Note that it is gdb segfaulting there, not HelloWorld.  So, any clues there? Am I totally braindead?  

I don't think your out of your mind. Well, at least you're not alone!

> Does insight get compiled with optimization on by default? In any case, I'm reconfiguring with CFLAGS=-g -O0 right now.  I'll post results in a bit.

Yes, that's right: the toolchain, by default, uses -O2. You can
configure with CFLAGS="-g" or something to supress it (this is how I do
it):

$ CFLAGS="-g" /path/to/src/configure --prefix=...

Keith



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]