View mode: basic / threaded / horizontal-split · Log in · Help
July 13, 2010
Re: Debugging
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
Re: Debugging
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
Re: Debugging
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...
Top | Discussion index | About this forum | D home