Bug 136 – gdb: Corrupt backtrace

void main() { static int i = 0; while(i++ < 10) main(); *(cast(int *)0) = 0; } On DMD 0.157 compiling with dmd -g -debug and running in gdb and printing a backtrace gives: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208064320 (LWP 23068)] 0x0804b1fa in _Dmain () at debug.d:5 5 *(cast(int *)0) = 0; Current language: auto; currently minimal (gdb) bt #0 0x0804b1fa in _Dmain () at debug.d:5 #1 0x0012d4f8 in ?? () #2 0xbfffecc0 in ?? () #3 0x0804b1f4 in _Dmain () at debug.d:4 Previous frame inner to this frame (corrupt stack?) Compared to DMD 0.156: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208064320 (LWP 23192)] 0x0804b1fa in _Dmain () at debug.d:5 5 *(cast(int *)0) = 0; Current language: auto; currently minimal (gdb) bt #0 0x0804b1fa in _Dmain () at debug.d:5 #1 0x0804b1f4 in _Dmain () at debug.d:4 #2 0x0804b1f4 in _Dmain () at debug.d:4 #3 0x0804b1f4 in _Dmain () at debug.d:4 #4 0x0804b1f4 in _Dmain () at debug.d:4 #5 0x0804b1f4 in _Dmain () at debug.d:4 #6 0x0804b1f4 in _Dmain () at debug.d:4 #7 0x0804b1f4 in _Dmain () at debug.d:4 #8 0x0804b1f4 in _Dmain () at debug.d:4 #9 0x0804b1f4 in _Dmain () at debug.d:4 #10 0x0804b1f4 in _Dmain () at debug.d:4 #11 0x0804b26f in main ()

Many gdb's fail with the -g switch. Use -gc instead. With -gc -debug, the backtrace works fine on my machine: gdb 5.3 i386-redhat-linux-gnu

[email protected] wrote: > http://d.puremagic.com/bugzilla/show_bug.cgi?id=136 > > > [email protected] changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |WORKSFORME > > > > > ------- Comment #1 from [email protected] 2006-05-12 03:53 ------- > Many gdb's fail with the -g switch. Use -gc instead. With -gc -debug, the > backtrace works fine on my machine: > > gdb 5.3 > i386-redhat-linux-gnu > > > -- Hmm, -gc is not listed in DMD's help ? I see it is under the linux version on http://www.digitalmars.com/d/dcompiler.html, but not if you do "dmd" on the linux command line. Looked for it on all the latest version.

Maybe this is really a GDB bug, but the error remains with -gc. On i686-pc-linux-gnu (RedHat EL4), with all of the following gdb versions: gdb 6.4 + d symbol demangling patches gdb 6.4 vanilla gdb 6.3 gdb 6.0 (I was unable to get gdb 5.3 and 5.2.1 to work on my system) compiled with: dmd -gc => corrupt backtrace dmd -g => corrupt backtrace dmd => OK backtrace with DMD 0.156 and earlier, the back traces work fine with all above combinations.

I just want to note that since this failed after upgrading DMD (not GDB) this can hardly be considered the fault of GDB. Would be nice to have it working.

(In reply to comment #4) > I just want to note that since this failed after upgrading DMD > (not GDB) this can hardly be considered the fault of GDB. This isn't a code generation issue. It might be related to incomplete/incorrect debugging information. # import cn.kuehne.flectioned; // for print_trace # # void main() { # static int i = 0; # while(i++ < 10) # main(); # *(cast(int *)0) = 0; # } dmd -g test.d flectioned.d gdb ./test [...] (gdb) run Starting program: /cage/test.d [Thread debugging using libthread_db enabled] [New Thread 4158367408 (LWP 23206)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 4158367408 (LWP 23206)] 0x0804af4a in _Dmain () at a.d:16 16 *(cast(int *)0) = 0; Current language: auto; currently minimal (gdb) bt #0 0x0804af4a in _Dmain () at a.d:16 #1 0xf7cbdb00 in ?? () #2 0xfff775a0 in ?? () #3 0x0804af44 in _Dmain () at a.d:15 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) call print_trace($ebp) 0xfff775a0 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775a8 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775b0 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775b8 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775c0 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775c8 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775d0 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775d8 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775e0 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff775e8 0x804af44 int main(char[][]) (0x804af2c, 36) 0xfff77618 0x8052269 extern(C) int main(int, char**) (0x80521a0, 279) call_trace only uses stack/frame pointers and those seem to be OK. DMD-0.155's doesn't show this issue but DMD-0.157 does. Added to DStress as http://dstress.kuehne.cn/norun/d/debug_info_12_A.d

This is defiantly a DMD issue. DMD-0.157 produces a .debug_frame section whereas DMD-0.155 doesn't. If the .debug_frame section is removed GDB displays the correct trace. dmd-0.157 -c -g a.d && objcopy -R .debug_frame a.o b.o && dmd-0.157 b.o -ofb && gdb ./b (gdb) run Starting program: /tmp/b [Thread debugging using libthread_db enabled] [New Thread 4157970096 (LWP 113)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 4157970096 (LWP 113)] 0x0804a09a in _Dmain () at a.d:5 5 *(cast(int *)0) = 0; Current language: auto; currently minimal (gdb) bt #0 0x0804a09a in _Dmain () at a.d:5 #1 0x0804a094 in _Dmain () at a.d:4 #2 0x0804a094 in _Dmain () at a.d:4 #3 0x0804a094 in _Dmain () at a.d:4 #4 0x0804a094 in _Dmain () at a.d:4 #5 0x0804a094 in _Dmain () at a.d:4 #6 0x0804a094 in _Dmain () at a.d:4 #7 0x0804a094 in _Dmain () at a.d:4 #8 0x0804a094 in _Dmain () at a.d:4 #9 0x0804a094 in _Dmain () at a.d:4 #10 0x0804a094 in _Dmain () at a.d:4 #11 0x0804a163 in main ()

Have tried with dmd 1.009 on a Fedora6 box. Zero shows the same behavior (line 4 shows up in the stack trace several times), and gdb (6.5-15.fc6rh) says: (gdb) run Starting program: /home/cristiv/dmd/bug [Thread debugging using libthread_db enabled] [New Thread 1235648 (LWP 18592)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1235648 (LWP 18592)] 0x08049e46 in _Dmain () at bug.d:5 5 *(cast(int *)0) = 0; Current language: auto; currently minimal (gdb) bt #0 0x08049e46 in _Dmain () at bug.d:5 #1 0x00d316c8 in _r_debug () #2 0xbf865250 in ?? () #3 0x08049e40 in _Dmain () at bug.d:4 Previous frame inner to this frame (corrupt stack?)

This seems to be working in DMD 1.049 and 2.034. I'm trying to organize GDB-related bugs, so I will close this one. Please let me know if I shouldn't be closing bugs and feel free to reopen it if still having this problem.