www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Stack tracing on Linux ?

reply Georg Wrede <georg.wrede iki.fi> writes:
With gdb I can either debug a core dump or an actual running process. 
For example, with

import std.stdio;

int main()
{
     readWrite();
     return 8;
}

void readWrite()
{
     auto line = readln();   // here it waits, and that's when I debug
                             // in another window
     write("Rivi oli: ", line);
}

I get the following stack trace (it looks the same whether I debug a 
core dump or a running instance)

#0  0x00251416 in __kernel_vsyscall ()
#1  0x00591a93 in __read_nocancel () from /lib/libc.so.6
#2  0x00528cee in _IO_new_file_underflow (fp=0x62e420) at fileops.c:598
#3  0x0052c17a in __underflow (fp=0x62e420) at genops.c:361
#4  0x0051e648 in _IO_getdelim (lineptr=0xbf94ec8c, n=0xbf94ec90,
     delimiter=10, fp=0x62e420) at iogetdelim.c:79
#5  0x080505bb in _D3std5stdio6readlnFPS3std1c5stdio6_iobufKAawZk ()
#6  0x080504d0 in _D3std5stdio6readlnFPS3std1c5stdio6_iobufwZAya ()
#7  0x0804931a in _D5read29readWriteFZv ()
#8  0x00000000 in ?? ()

This is not perfect, 5..7 are functions written in D, but main is 
missing. Then, trying to examine a core dump from something that gets a 
segfault, I wrote the following, expecting that I'd get a grandiose 
stack trace


$ cat npe.d
import std.stdio;

int main()
{
     return foo(3);
}

int foo(int a)
{
     return 1 + bar(a - 3);
}

int bar(int b)
{
     return 1 + car(b - 3);
}

int car(int c)
{
     return 1 + dar(c - 3);
}

int dar(int d)
{
     return 1 + * cast(int*) d; // null pointer exception
}



Turns out I got zilch!

#0  0x08049118 in _D3npe3darFiZi ()
#1  0xfffffffa in ?? ()

I have DMD on Fedora 10, and used
dmd -g -debug -v read2.d
to compile. Incidentally, using
dmd -gc -debug -v read2.d
does seem to give the same stack trace.
Apr 02 2009
next sibling parent reply "Simon Gomizelj" <simongmzlj gmail.com> writes:
On Thu, 02 Apr 2009 04:56:46 -0400, Georg Wrede <georg.wrede iki.fi> wrote:

 With gdb I can either debug a core dump or an actual running process.  
 For example, with

 import std.stdio;

 int main()
 {
      readWrite();
      return 8;
 }

 void readWrite()
 {
      auto line = readln();   // here it waits, and that's when I debug
                              // in another window
      write("Rivi oli: ", line);
 }

 I get the following stack trace (it looks the same whether I debug a  
 core dump or a running instance)

 #0  0x00251416 in __kernel_vsyscall ()
 #1  0x00591a93 in __read_nocancel () from /lib/libc.so.6
 #2  0x00528cee in _IO_new_file_underflow (fp=0x62e420) at fileops.c:598
 #3  0x0052c17a in __underflow (fp=0x62e420) at genops.c:361
 #4  0x0051e648 in _IO_getdelim (lineptr=0xbf94ec8c, n=0xbf94ec90,
      delimiter=10, fp=0x62e420) at iogetdelim.c:79
 #5  0x080505bb in _D3std5stdio6readlnFPS3std1c5stdio6_iobufKAawZk ()
 #6  0x080504d0 in _D3std5stdio6readlnFPS3std1c5stdio6_iobufwZAya ()
 #7  0x0804931a in _D5read29readWriteFZv ()
 #8  0x00000000 in ?? ()

 This is not perfect, 5..7 are functions written in D, but main is  
 missing. Then, trying to examine a core dump from something that gets a  
 segfault, I wrote the following, expecting that I'd get a grandiose  
 stack trace


 $ cat npe.d
 import std.stdio;

 int main()
 {
      return foo(3);
 }

 int foo(int a)
 {
      return 1 + bar(a - 3);
 }

 int bar(int b)
 {
      return 1 + car(b - 3);
 }

 int car(int c)
 {
      return 1 + dar(c - 3);
 }

 int dar(int d)
 {
      return 1 + * cast(int*) d; // null pointer exception
 }



 Turns out I got zilch!

 #0  0x08049118 in _D3npe3darFiZi ()
 #1  0xfffffffa in ?? ()

 I have DMD on Fedora 10, and used
 dmd -g -debug -v read2.d
 to compile. Incidentally, using
 dmd -gc -debug -v read2.d
 does seem to give the same stack trace.

While I can't explain why gdb and dmd don't seem to work nicely together, you'd have much better luck using ldc. Compiling with ldc, this is the backtrace I got when debugging read2.d on my maching (and is what you're probably looking for): (gdb) run Starting program: /data/Code/D/error [Thread debugging using libthread_db enabled] [New Thread 0xb7d656c0 (LWP 14104)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7d656c0 (LWP 14104)] 0x080495fe in _D5error3darFiZi (d=-6) at error.d:23 23 return 1 + * cast(int*) d; // null pointer exception (gdb) backtrace #0 0x080495fe in _D5error3darFiZi (d=-6) at error.d:23 #1 0x080495e3 in _D5error3carFiZi (c=-3) at error.d:18 #2 0x080495c3 in _D5error3barFiZi (b=0) at error.d:13 #3 0x080495a3 in _D5error3fooFiZi (a=3) at error.d:8 #4 0x0804957d in _Dmain () at error.d:3 #5 0x0804dd0a in _D6dmain24mainUiPPaPPaZi7runMainMFZv () #6 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv () #7 0x0804dd4d in _D6dmain24mainUiPPaPPaZi6runAllMFZv () #8 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv () #9 0x0804d946 in main () -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Apr 03 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Simon Gomizelj wrote:
 On Thu, 02 Apr 2009 04:56:46 -0400, Georg Wrede <georg.wrede iki.fi> wrote:
 
 With gdb I can either debug a core dump or an actual running process. 
 For example, with

 import std.stdio;

 int main()
 {
      readWrite();
      return 8;
 }

 void readWrite()
 {
      auto line = readln();   // here it waits, and that's when I debug
                              // in another window
      write("Rivi oli: ", line);
 }

 I get the following stack trace (it looks the same whether I debug a 
 core dump or a running instance)

 #0  0x00251416 in __kernel_vsyscall ()
 #1  0x00591a93 in __read_nocancel () from /lib/libc.so.6
 #2  0x00528cee in _IO_new_file_underflow (fp=0x62e420) at fileops.c:598
 #3  0x0052c17a in __underflow (fp=0x62e420) at genops.c:361
 #4  0x0051e648 in _IO_getdelim (lineptr=0xbf94ec8c, n=0xbf94ec90,
      delimiter=10, fp=0x62e420) at iogetdelim.c:79
 #5  0x080505bb in _D3std5stdio6readlnFPS3std1c5stdio6_iobufKAawZk ()
 #6  0x080504d0 in _D3std5stdio6readlnFPS3std1c5stdio6_iobufwZAya ()
 #7  0x0804931a in _D5read29readWriteFZv ()
 #8  0x00000000 in ?? ()

 This is not perfect, 5..7 are functions written in D, but main is 
 missing. Then, trying to examine a core dump from something that gets 
 a segfault, I wrote the following, expecting that I'd get a grandiose 
 stack trace


 $ cat npe.d
 import std.stdio;

 int main()
 {
      return foo(3);
 }

 int foo(int a)
 {
      return 1 + bar(a - 3);
 }

 int bar(int b)
 {
      return 1 + car(b - 3);
 }

 int car(int c)
 {
      return 1 + dar(c - 3);
 }

 int dar(int d)
 {
      return 1 + * cast(int*) d; // null pointer exception
 }



 Turns out I got zilch!

 #0  0x08049118 in _D3npe3darFiZi ()
 #1  0xfffffffa in ?? ()

 I have DMD on Fedora 10, and used
 dmd -g -debug -v read2.d
 to compile. Incidentally, using
 dmd -gc -debug -v read2.d
 does seem to give the same stack trace.

While I can't explain why gdb and dmd don't seem to work nicely together, you'd have much better luck using ldc. Compiling with ldc, this is the backtrace I got when debugging read2.d on my maching (and is what you're probably looking for): (gdb) run Starting program: /data/Code/D/error [Thread debugging using libthread_db enabled] [New Thread 0xb7d656c0 (LWP 14104)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7d656c0 (LWP 14104)] 0x080495fe in _D5error3darFiZi (d=-6) at error.d:23 23 return 1 + * cast(int*) d; // null pointer exception (gdb) backtrace #0 0x080495fe in _D5error3darFiZi (d=-6) at error.d:23 #1 0x080495e3 in _D5error3carFiZi (c=-3) at error.d:18 #2 0x080495c3 in _D5error3barFiZi (b=0) at error.d:13 #3 0x080495a3 in _D5error3fooFiZi (a=3) at error.d:8 #4 0x0804957d in _Dmain () at error.d:3 #5 0x0804dd0a in _D6dmain24mainUiPPaPPaZi7runMainMFZv () #6 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv () #7 0x0804dd4d in _D6dmain24mainUiPPaPPaZi6runAllMFZv () #8 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv () #9 0x0804d946 in main ()

Ah, this looks nice. And the file name shows in the function names. If everyone wasn't telling me it's a licence issue, I'd take it for granted there's a bug in DMD.
Apr 02 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-04-02 20:51:26 +0200, Georg Wrede <georg.wrede iki.fi> said:

 Simon Gomizelj wrote:
 On Thu, 02 Apr 2009 04:56:46 -0400, Georg Wrede <georg.wrede iki.fi> wrote:
 
 With gdb I can either debug a core dump or an actual running process. 
 For example, with
 
 import std.stdio;
 
 int main()
 {
      readWrite();
      return 8;
 }
 
 void readWrite()
 {
      auto line = readln();   // here it waits, and that's when I debug
                              // in another window
      write("Rivi oli: ", line);
 }
 
 I get the following stack trace (it looks the same whether I debug a 
 core dump or a running instance)
 
 #0  0x00251416 in __kernel_vsyscall ()
 #1  0x00591a93 in __read_nocancel () from /lib/libc.so.6
 #2  0x00528cee in _IO_new_file_underflow (fp=0x62e420) at fileops.c:598
 #3  0x0052c17a in __underflow (fp=0x62e420) at genops.c:361
 #4  0x0051e648 in _IO_getdelim (lineptr=0xbf94ec8c, n=0xbf94ec90,
      delimiter=10, fp=0x62e420) at iogetdelim.c:79
 #5  0x080505bb in _D3std5stdio6readlnFPS3std1c5stdio6_iobufKAawZk ()
 #6  0x080504d0 in _D3std5stdio6readlnFPS3std1c5stdio6_iobufwZAya ()
 #7  0x0804931a in _D5read29readWriteFZv ()
 #8  0x00000000 in ?? ()
 
 This is not perfect, 5..7 are functions written in D, but main is 
 missing. Then, trying to examine a core dump from something that gets a 
 segfault, I wrote the following, expecting that I'd get a grandiose 
 stack trace
 
 
 $ cat npe.d
 import std.stdio;
 
 int main()
 {
      return foo(3);
 }
 
 int foo(int a)
 {
      return 1 + bar(a - 3);
 }
 
 int bar(int b)
 {
      return 1 + car(b - 3);
 }
 
 int car(int c)
 {
      return 1 + dar(c - 3);
 }
 
 int dar(int d)
 {
      return 1 + * cast(int*) d; // null pointer exception
 }
 
 
 
 Turns out I got zilch!
 
 #0  0x08049118 in _D3npe3darFiZi ()
 #1  0xfffffffa in ?? ()
 
 I have DMD on Fedora 10, and used
 dmd -g -debug -v read2.d
 to compile. Incidentally, using
 dmd -gc -debug -v read2.d
 does seem to give the same stack trace.
 

While I can't explain why gdb and dmd don't seem to work nicely together, you'd have much better luck using ldc. Compiling with ldc, this is the backtrace I got when debugging read2.d on my maching (and is what you're probably looking for): (gdb) run Starting program: /data/Code/D/error [Thread debugging using libthread_db enabled] [New Thread 0xb7d656c0 (LWP 14104)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7d656c0 (LWP 14104)] 0x080495fe in _D5error3darFiZi (d=-6) at error.d:23 23 return 1 + * cast(int*) d; // null pointer exception (gdb) backtrace #0 0x080495fe in _D5error3darFiZi (d=-6) at error.d:23 #1 0x080495e3 in _D5error3carFiZi (c=-3) at error.d:18 #2 0x080495c3 in _D5error3barFiZi (b=0) at error.d:13 #3 0x080495a3 in _D5error3fooFiZi (a=3) at error.d:8 #4 0x0804957d in _Dmain () at error.d:3 #5 0x0804dd0a in _D6dmain24mainUiPPaPPaZi7runMainMFZv () #6 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv () #7 0x0804dd4d in _D6dmain24mainUiPPaPPaZi6runAllMFZv () #8 0x0804d9c7 in _D6dmain24mainUiPPaPPaZi7tryExecMFDFZvZv () #9 0x0804d946 in main ()

Ah, this looks nice. And the file name shows in the function names. If everyone wasn't telling me it's a licence issue,

 I'd take it for granted there's a bug in DMD.

you are right, on mac with dmd I get the full trace, on linux not. About the missing line and file information I think dmd does not add that on mac/linux.
Apr 03 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Fawzi Mohamed wrote:
 you are right, on mac with dmd I get the full trace, on linux not. About 
 the missing line and file information I think dmd does not add that on 
 mac/linux.

You can see using dumpobj -p on the object files that dmd *does* put in the information.
Apr 03 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-04-03 10:33:19 +0200, Walter Bright <newshound1 digitalmars.com> said:

 Fawzi Mohamed wrote:
 you are right, on mac with dmd I get the full trace, on linux not. 
 About the missing line and file information I think dmd does not add 
 that on mac/linux.

You can see using dumpobj -p on the object files that dmd *does* put in the information.

then the correct statement is that libbdf is not able to interpret that information correctly, because both on mac and on linux gdb and addr2line are not able to use it
Apr 03 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Fawzi Mohamed wrote:
 then the correct statement is that libbdf is not able to interpret that 
 information correctly, because both on mac and on linux gdb and 
 addr2line are not able to use it

Right. I just don't know what is wrong with it. It appears to be correct according to the dwarf spec.
Apr 03 2009
prev sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
Well inlined functions will have no frame, also last call optimization 
(tail optimization) removes the frame.
the backtrace typically gets the return address (i.e. the adress of the 
next instruction, not of the calling instruction).
Normally the code tries to guess the calling instruction as the one 
before the return instruction, but it does not always work.
So one has to expect that the backtrace might miss some frames.
But normally this is not a problem.
The tracing of tango svn version (that uses libc backtrace) seems to 
work rather well.
It does not give you the names, but as said that is due to a license problem.

gdb uses the same tools (and libbdf), that as jive has shown works well 
(but is GPL).
So I think that things are working as expected, even if maybe not as 
you would like :)

Fawzi

On 2009-04-02 10:56:46 +0200, Georg Wrede <georg.wrede iki.fi> said:

 With gdb I can either debug a core dump or an actual running process. 
 For example, with
 
 import std.stdio;
 
 int main()
 {
      readWrite();
      return 8;
 }
 
 void readWrite()
 {
      auto line = readln();   // here it waits, and that's when I debug
                              // in another window
      write("Rivi oli: ", line);
 }
 
 I get the following stack trace (it looks the same whether I debug a 
 core dump or a running instance)
 
 #0  0x00251416 in __kernel_vsyscall ()
 #1  0x00591a93 in __read_nocancel () from /lib/libc.so.6
 #2  0x00528cee in _IO_new_file_underflow (fp=0x62e420) at fileops.c:598
 #3  0x0052c17a in __underflow (fp=0x62e420) at genops.c:361
 #4  0x0051e648 in _IO_getdelim (lineptr=0xbf94ec8c, n=0xbf94ec90,
      delimiter=10, fp=0x62e420) at iogetdelim.c:79
 #5  0x080505bb in _D3std5stdio6readlnFPS3std1c5stdio6_iobufKAawZk ()
 #6  0x080504d0 in _D3std5stdio6readlnFPS3std1c5stdio6_iobufwZAya ()
 #7  0x0804931a in _D5read29readWriteFZv ()
 #8  0x00000000 in ?? ()
 
 This is not perfect, 5..7 are functions written in D, but main is 
 missing. Then, trying to examine a core dump from something that gets a 
 segfault, I wrote the following, expecting that I'd get a grandiose 
 stack trace
 
 
 $ cat npe.d
 import std.stdio;
 
 int main()
 {
      return foo(3);
 }
 
 int foo(int a)
 {
      return 1 + bar(a - 3);
 }
 
 int bar(int b)
 {
      return 1 + car(b - 3);
 }
 
 int car(int c)
 {
      return 1 + dar(c - 3);
 }
 
 int dar(int d)
 {
      return 1 + * cast(int*) d; // null pointer exception
 }
 
 
 
 Turns out I got zilch!
 
 #0  0x08049118 in _D3npe3darFiZi ()
 #1  0xfffffffa in ?? ()
 
 I have DMD on Fedora 10, and used
 dmd -g -debug -v read2.d
 to compile. Incidentally, using
 dmd -gc -debug -v read2.d
 does seem to give the same stack trace.

Apr 02 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Fawzi Mohamed wrote:
 Well inlined functions will have no frame, also last call optimization 
 (tail optimization) removes the frame.

If I were to write a compiler, then using "-g -debug", etc. would make sure neither happens!
 the backtrace typically gets the return address (i.e. the adress of the 
 next instruction, not of the calling instruction).
 Normally the code tries to guess the calling instruction as the one 
 before the return instruction, but it does not always work.

A first idea is to have the compiler insert a few NOPs when compiling with -debug, but then again if it were that easy, somebody else would've thought of it already.
 So one has to expect that the backtrace might miss some frames.
 But normally this is not a problem.

While I've seldom needed debuggin tools or stack tracing, I can imagine they're indispensable for people who have to quickly fix others' code. I guess most folks here, especially Walter(?) really do most of their coding on "new" and "own" things, where there's less need for such? But in a busy corporate environment with dozens of coders on the project, and people having to debug (or actually ending up because the called function doesn't work right) each other's code, it's different.
 The tracing of tango svn version (that uses libc backtrace) seems to 
 work rather well.
 It does not give you the names, but as said that is due to a license 
 problem.

Aarrghhh. What most frustrates me is when something obvious can't be done because of external trivialities.
 gdb uses the same tools (and libbdf), that as jive has shown works well 
 (but is GPL).
 So I think that things are working as expected, even if maybe not as you 
 would like :)

It's a shame.
Apr 02 2009
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Georg Wrede (georg.wrede iki.fi)'s article
 Fawzi Mohamed wrote:
 The tracing of tango svn version (that uses libc backtrace) seems to
 work rather well.
 It does not give you the names, but as said that is due to a license
 problem.

done because of external trivialities.

The Tango plugin architecture for backtrace was designed so that the backtrace code doesn't have to be integrated into Tango itself, eliminating the license problem. But I can see how this might be a problem if you want to bundle a backtrace library with Tango :-)
Apr 02 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-04-02 21:18:55 +0200, Sean Kelly <sean invisibleduck.org> said:

 == Quote from Georg Wrede (georg.wrede iki.fi)'s article
 Fawzi Mohamed wrote:
 
 The tracing of tango svn version (that uses libc backtrace) seems to
 work rather well.
 It does not give you the names, but as said that is due to a license
 problem.

done because of external trivialities.

The Tango plugin architecture for backtrace was designed so that the backtrace code doesn't have to be integrated into Tango itself, eliminating the license problem. But I can see how this might be a problem if you want to bundle a backtrace library with Tango :-)

having some stacktracing by default there was the number one request at the tango reference, and also in the wish list for a while. The idea is not to disallow external solutions, but to have something working there by default. Please note that something using GPL code even as plugin forces the whole application to be GPL, which is not acceptable for anyone not wanting to release its application as GPL. Fawzi
Apr 03 2009
parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fawzi Mohamed wrote:
 On 2009-04-02 21:18:55 +0200, Sean Kelly <sean invisibleduck.org> said:
 
 == Quote from Georg Wrede (georg.wrede iki.fi)'s article
 Fawzi Mohamed wrote:
 The tracing of tango svn version (that uses libc backtrace) seems to
 work rather well.
 It does not give you the names, but as said that is due to a license
 problem.

done because of external trivialities.

The Tango plugin architecture for backtrace was designed so that the backtrace code doesn't have to be integrated into Tango itself, eliminating the license problem. But I can see how this might be a problem if you want to bundle a backtrace library with Tango :-)

having some stacktracing by default there was the number one request at the tango reference, and also in the wish list for a while. The idea is not to disallow external solutions, but to have something working there by default. Please note that something using GPL code even as plugin forces the whole application to be GPL, which is not acceptable for anyone not wanting to release its application as GPL.

backtrace_symbols) and it's licensed under the LGPL, so there should be no problem... Jerome - -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknXbuQACgkQd0kWM4JG3k8AxQCeOws+fxLtAa0wbZ0YDiVgFyaQ ht4AoLODMa7nV9eNtyRKoDbqrymcJcPQ =BzNy -----END PGP SIGNATURE-----
Apr 04 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:
 Fawzi Mohamed wrote:
 Well inlined functions will have no frame, also last call optimization 
 (tail optimization) removes the frame.

If I were to write a compiler, then using "-g -debug", etc. would make sure neither happens!

However, closures in D1 have a stack frame that is within the creating function's stack frame, and gdb assumes that means a corrupt stack. There's no real way around this.
Apr 03 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-04-03 19:24:25 +0200, Christopher Wright <dhasenan gmail.com> said:

 Georg Wrede wrote:
 Fawzi Mohamed wrote:
 Well inlined functions will have no frame, also last call optimization 
 (tail optimization) removes the frame.

If I were to write a compiler, then using "-g -debug", etc. would make sure neither happens!

However, closures in D1 have a stack frame that is within the creating function's stack frame, and gdb assumes that means a corrupt stack. There's no real way around this.

Now this is more clear, thanks!
Apr 03 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Fawzi Mohamed wrote:
 On 2009-04-03 19:24:25 +0200, Christopher Wright <dhasenan gmail.com> said:
 
 Georg Wrede wrote:
 Fawzi Mohamed wrote:
 Well inlined functions will have no frame, also last call 
 optimization (tail optimization) removes the frame.

If I were to write a compiler, then using "-g -debug", etc. would make sure neither happens!

However, closures in D1 have a stack frame that is within the creating function's stack frame, and gdb assumes that means a corrupt stack. There's no real way around this.

Now this is more clear, thanks!

If the current D closure architecture is considered stable and permanent, then maybe the gdb or glibc folks might want to look at it? And while at it, they'd probably know right off the bat what seems to be the problem with D stack traces not currently showing properly.
Apr 10 2009