• Jesse Phillips <jessekphillips+D gmail.com> Jul 13 2010
• Graham St Jack <Graham.StJack internode.on.net> Jul 13 2010
• Leandro Lucarella <luca llucax.com.ar> Jul 13 2010

Jesse Phillips <jessekphillips+D gmail.com> writes:

Graham St Jack Wrote:

 Specifically:
 
 Stack Trace:
 ------------
 
 I can't get the D2 stack-trace to work properly. All I get is something 
 like this, which isn't helpful:
 
 Segmentation fault
 
 The code I used to generate this was:
 import std.stdio;
 import std.file;
 void foo(File file) {
     file.flush;
 }
 void main(string[] args) {
     File file;
     foo(file);
 }
 Is stack-trace support broken, or do I have to do something to enable it?


While you aren't asking why, 'file' is initialized to null and is not a stack
allocated class as it would be in C++.

The first step to debugging is to use the -gc flag instead of -g. The
unreleased version of GDB has the patch for D mangling, otherwise you need the
symbols to mimic C. Then you can run your program with GDB.

As you should be familiar with. You can get the stack trace form GDB if you
enable core dumps: $ ulimit -c 5000 && dmd -gc test.d && ./test && gdb ./test
core

Graham St Jack <Graham.StJack internode.on.net> writes:

On Tue, 13 Jul 2010 15:29:35 -0400, Jesse Phillips wrote:

 Graham St Jack Wrote:
 
 Specifically:
 
 Stack Trace:
 ------------
 
 I can't get the D2 stack-trace to work properly. All I get is something
 like this, which isn't helpful:
 
 Segmentation fault
 
 The code I used to generate this was: import std.stdio;
 import std.file;
 void foo(File file) {
     file.flush;
 }
 void main(string[] args) {
     File file;
     foo(file);
 }
 Is stack-trace support broken, or do I have to do something to enable
 it?


 While you aren't asking why, 'file' is initialized to null and is not a
 stack allocated class as it would be in C++.


Yes - it was a contrived example designed to deliberately segfault.

 
 The first step to debugging is to use the -gc flag instead of -g. The
 unreleased version of GDB has the patch for D mangling, otherwise you
 need the symbols to mimic C. Then you can run your program with GDB.


Thanks - I have been doing that, but like I said, it is hard work 
mentally demangling the names.

 
 As you should be familiar with. You can get the stack trace form GDB if
 you enable core dumps: $ ulimit -c 5000 && dmd -gc test.d && ./test &&
 gdb ./test core


I didn't know about that, thanks. It looks like a more convenient way of 
debugging segfaults than running the program in gdb directly. I will give 
it a go.

Leandro Lucarella <luca llucax.com.ar> writes:

Graham St Jack, el 13 de julio a las 21:47 me escribiste:
 As you should be familiar with. You can get the stack trace form GDB if
 you enable core dumps: $ ulimit -c 5000 && dmd -gc test.d && ./test &&
 gdb ./test core


 I didn't know about that, thanks. It looks like a more convenient way of 
 debugging segfaults than running the program in gdb directly. I will give 
 it a go.


``ulimit -c 5000`` will not generate a core dump if the dump is bigger
than 5000 bytes (or kb?), if you want no limits, use ``ulimit -c
unlimited`` instead.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y tuve amores, que fue uno sólo
El que me dejó de a pie y me enseñó todo...