Stack tracing on Linux ?

[Fawzi Mohamed]

On 2009-04-02 20:51:26 +0200, Georg Wrede <georg.wrede at iki.fi> said:

> Simon Gomizelj wrote:
>> On Thu, 02 Apr 2009 04:56:46 -0400, Georg Wrede <georg.wrede at 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,
No the license issue is just for including this in tango

> 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.