Thread overview
Re: Debugging
Jul 13, 2010
Jesse Phillips
Jul 13, 2010
Graham St Jack
Jul 13, 2010
Leandro Lucarella
July 13, 2010
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
July 13, 2010
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.
July 13, 2010
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...