pending/1288: possible gdb bug?

["Kevin Powell" <KPowell at sirf dot com>]

>Number:         1288
>Category:       pending
>Synopsis:       possible gdb bug?
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Thu Jul 17 19:28:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 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=20
 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: =20
 
 gdb/dwarf2-frame.c:508 fs->data_align =3D =
 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.
 =20
 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=3D1, argv=3D0xa042a68) at HelloWorld.c:5
 5               printf ("Hello World!\n");
 (gdb) n
 
 Program received signal SIGSEGV, Segmentation fault.
 0x0057f581 in dwarf2_frame_cache (next_frame=3D0x101231b8, =
 this_cache=3D0x10123224)
 at ../../insight+dejagnu-20030621/gdb/dwarf2-frame.c:508
 508       fs->data_align =3D fde->cie->data_alignment_factor;
 (gdb) bt
 #0  0x0057f581 in dwarf2_frame_cache (next_frame=3D0x101231b8, =
 this_cache=3D0x10123224) at =
 ./../insight+dejagnu-20030621/gdb/dwarf2-frame.c:508
 #1  0x0057f980 in dwarf2_frame_this_id (next_frame=3D0x101231b8, =
 this_cache=3D0x10123224, this_id=3D0x10123240) at =
 ./../insight+dejagnu-20030621/gdb/dwarf2-frame.c:599
 #2  0x00464398 in get_frame_id (fi=3D0x10123210) at =
 ./../insight+dejagnu-20030621/gdb/frame.c:243
 #3  0x0043a1d6 in step_1 (skip_subroutines=3D1, single_inst=3D0, =
 count_string=3D0x0) at ../../insight+dejagnu-20030621/gdb/infcmd.c:631
 #4  0x00439f7b in next_command (count_string=3D0x0, from_tty=3D1) at =
 ./../insight+dejagnu-20030621/gdb/infcmd.c:559
 #5  0x00405a9b in do_cfunc (c=3D0x1010e130, args=3D0x0, from_tty=3D1) at =
 ./../insight+dejagnu-20030621/gdb/cli/cli-decode.c:53
 #6  0x00408157 in cmd_func (cmd=3D0x1010e130, args=3D0x0, from_tty=3D1) =
 at ../../insight+dejagnu-20030621/gdb/cli/cli-decode.c:1517
 #7  0x00424d8a in execute_command (p=3D0x10102ce9 "", from_tty=3D1) at =
 ./../insight+dejagnu-20030621/gdb/top.c:716
 #8  0x0048bd6a in command_handler (command=3D0x10102ce8 "n") at =
 ./../insight+dejagnu-20030621/gdb/event-top.c:500
 #9  0x0048c58b in command_line_handler (rl=3D0x1011c8e8 "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=3D0x0) at =
 ./../insight+dejagnu-20030621/gdb/event-top.c:166
 #12 0x0048bb97 in stdin_event_handler (error=3D0, client_data=3D0x0) at =
 ./../insight+dejagnu-20030621/gdb/event-top.c:416
 #13 0x004a75ab in handle_file_event (event_file_desc=3D0) 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=3D0x0) at =
 ./../insight+dejagnu-20030621/gdb/event-loop.c:371
 #16 0x004248be in do_catch_errors (uiout=3D0x10125708, data=3D0x22f868) =
 at ../../insight+dejagnu-20030621/gdb/top.c:497
 #17 0x004246be in catcher (func=3D0x4248a2 <do_catch_errors>, =
 func_uiout=3D0x10125708, func_args=3D0x22f868, func_val=3D0x22f874, =
 func_caught=3D0x22f870, errstring=3D0x4a6df7 "", mask=3D6) at =
 ./../insight+dejagnu-20030621/gdb/top.c:429
 #18 0x0042490a in catch_errors (func=3D0x4a6daa <gdb_do_one_event>, =
 func_args=3D0x0, errstring=3D0x4a6df7 "", mask=3D6) 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=3D0x0) at =
 ./../insight+dejagnu-20030621/gdb/main.c:97
 #23 0x004248be in do_catch_errors (uiout=3D0x10125708, data=3D0x22fa58) =
 at ../../insight+dejagnu-20030621/gdb/top.c:497
 #24 0x004246be in catcher (func=3D0x4248a2 <do_catch_errors>, =
 func_uiout=3D0x10125708, func_args=3D0x22fa58, func_val=3D0x22fa64, =
 func_caught=3D0x22fa60, errstring=3D0x401260 "", mask=3D6) at =
 ./../insight+dejagnu-20030621/gdb/top.c:429
 #25 0x0042490a in catch_errors (func=3D0x401100 <captured_command_loop>, =
 func_args=3D0x0, errstring=3D0x401260 "", mask=3D6) at =
 ./../insight+dejagnu-20030621/gdb/top.c:509
 #26 0x0040263d in captured_main (data=3D0x22fd98) at =
 ./../insight+dejagnu-20030621/gdb/main.c:811
 #27 0x004248be in do_catch_errors (uiout=3D0x677420, data=3D0x22fd38) at =
 ./../insight+dejagnu-20030621/gdb/top.c:497
 #28 0x004246be in catcher (func=3D0x4248a2 <do_catch_errors>, =
 func_uiout=3D0x677420, func_args=3D0x22fd38, func_val=3D0x22fd44, =
 func_caught=3D0x22fd40, errstring=3D0x401260 "", mask=3D6) at =
 ./../insight+dejagnu-20030621/gdb/top.c:429
 #29 0x0042490a in catch_errors (func=3D0x4014be <captured_main>, =
 func_args=3D0x22fd98, errstring=3D0x401260 "", mask=3D6) at =
 ./../insight+dejagnu-20030621/gdb/top.c:509
 #30 0x00402674 in gdb_main (args=3D0x22fd98) at =
 ./../insight+dejagnu-20030621/gdb/main.c:820
 #31 0x004010f6 in main (argc=3D1, argv=3D0x10102a68) 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 =3D (struct frame_info *) 0x101231b8
 this_cache =3D (void **) 0x10123224
 (gdb) info locals
 old_chain =3D (struct cleanup *) 0x1011c778
 num_regs =3D 40
 cache =3D (struct dwarf2_frame_cache *) 0x101232b8
 fs =3D (struct dwarf2_frame_state *) 0x102056e0
 fde =3D (struct dwarf2_fde *) 0x10151db8
 reg =3D 6
 (gdb) p fde->cie
 $1 =3D (struct dwarf2_cie *) 0x0
 (gdb)
 
 Kevin Powell
 
 -----Original Message-----
 From: Keith Seitz
 Sent: Monday, June 23, 2003 6:18 PM
 To: Kevin Powell
 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? =20
 
 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=3D-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=3D"-g" or something to supress it (this is how I =
 do
 it):
 
 $ CFLAGS=3D"-g" /path/to/src/configure --prefix=3D...
 
 Keith
 
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: