Stack tracing on Linux ?

[Fawzi Mohamed]

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