Bug 8393 - possible gdb bug?
Summary: possible gdb bug?
Status: RESOLVED OBSOLETE
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-17 19:28 UTC by kpowell
Modified: 2014-09-15 21:28 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kpowell 2003-07-17 19:28:01 UTC
[Converted from Gnats 1288]

 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

Release:
unknown
Comment 1 Sergio Durigan Junior 2014-09-14 20:31:21 UTC
Keith, would you know if this bug is still valid?  It seems to me that it is not, since it has been so long and ISTR that Cygwin debugging is OK-ish...  But well, it mentions Insight and Cygwin, two things that I am not very familiar with.  So I decided to put you on the loop.
Comment 2 Keith Seitz 2014-09-15 21:24:38 UTC
(In reply to Sergio Durigan Junior from comment #1)
> Keith, would you know if this bug is still valid?  It seems to me that it is
> not, since it has been so long and ISTR that Cygwin debugging is OK-ish... 
> But well, it mentions Insight and Cygwin, two things that I am not very
> familiar with.  So I decided to put you on the loop.

Unfortunately, I don't recall if I ever attempted to reproduce the bug locally. Certainly no VM back then!

In any case, I certainly have debugged gdb/insight on Cygwin and not noticed any problems in quite a few years. I would say close this with the usual inactivity moniker and request a new bug be opened if it should prove necessary.
Comment 3 Sergio Durigan Junior 2014-09-15 21:28:44 UTC
Thanks a lot, Keith!  Closing as OBSOLETE due to lack of activity.  Feel free to reopen if necessary.