Re: Stack trace from core file without executable

[Ray Ruvinskiy <rruvinsk at sybase dot com>]

Paul,

I ran my test on Linux x86, and, yes, all I'm interested in is the PC  
addresses.

The motivation is to help with user core file debugging. Suppose a  
user is using some application that in turns uses my library, and the  
application then crashes in this library. If gdb could extract stack  
traces just from core files, I could avoid having to get my hands on  
the user's application. Instead, I could get the stack trace and  
resolve the relevant portions of it myself. To do that, I don't even  
strictly need my actual library; all I need is my library's objdump  
output (and the library's base load address). Now, it is true that I  
could ask the user to run gdb on their machine and send me the stack  
trace, but that adds to the turnaround time, and it would be more  
convenient if this step wasn't necessary.

As for output. fstack's no-executable output is as follows:

rruvinsk@rruvinsk-u804:~/software/frysk$ ./build/frysk-core/frysk/ 
bindir/fstack -noexe core
Task #23913
#0 0xb7f08410 in [unknown] from [vdso]
#1 0xb7dd5a01 in [unknown]
#2 0x0804838a in [unknown]
#3 0xb7dbf450 in [unknown]
#4 0x08048311 in [unknown]

If I specify the executable, I get:

rruvinsk@rruvinsk-u804:~/software/frysk$ ./build/frysk-core/frysk/ 
bindir/fstack -exe test core
Task #23913
#0 0xb7f08410 in [unknown] from [vdso]
#1 0xb7dd5a01 in abort() from libc.so.6
#2 0x0804838a in main() from test
#3 0xb7dbf450 in __libc_start_main() from libc.so.6
#4 0x08048311 in _start() from test

With gdb, if I don't specify the executable, I get:

rruvinsk@rruvinsk-u804:~/software/frysk$ gdb -ex bt --core=core
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html 
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show  
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
(no debugging symbols found)
Core was generated by `./test'.
Program terminated with signal 6, Aborted.
[New process 23913]
#0  0xb7f08410 in __kernel_vsyscall ()
#0  0xb7f08410 in __kernel_vsyscall ()
#1  0xb7dd4085 in ?? ()
#2  0xb7ef3ff4 in ?? ()
#3  0xbff8f6ac in ?? ()
#4  0xb7da86b0 in ?? ()
#5  0xbff8f738 in ?? ()
#6  0xb7dd5a01 in ?? ()
#7  0x00000006 in ?? ()
#8  0xbff8f6ac in ?? ()
#9  0x00000000 in ?? ()

With the executable:

rruvinsk@rruvinsk-u804:~/software/frysk$ gdb -ex bt test core
[ ... banner snipped ... ]
[New process 23913]
#0  0xb7f08410 in __kernel_vsyscall ()
#0  0xb7f08410 in __kernel_vsyscall ()
#1  0xb7dd4085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7dd5a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x0804838a in main () at test.c:5

test is:

#include <stdlib.h>

int main()
{
    abort();
}

compiled with:

gcc -g test.o -o test

Thanks,

Ray

On 18-Oct-08, at 6:19 PM, Paul Pluzhnikov wrote:

> On Sat, Oct 18, 2008 at 2:57 PM, Ray Ruvinskiy <rruvinsk@sybase.com>  
> wrote:
>
> > frysk's fstack had a feature that I found quite useful: the ability  
> > to
> > extract (fairly accurate) stack traces from core files without  
> > needing the
> > executable that generated them.
>
> On which platform? And what is contained in the frysk stack trace?
>
> AFAIU, it couldn't contain function names, as these aren't normally
> saved in the 'core' at all.
>
> Assuming frysk stack trace looks like a chain of program counters,
> what do you use it for? You still need the original executable to
> tell you what these addresses are (at which point you could just
> analyze the core with the executable in gdb, and get complete
> info).
>
> > gdb, on the other hand, does not appear to
> > be able to do this very well. (Running a simple executable that  
> > does nothing
> > but call abort() and then attempting to get the stack trace from the
> > resulting core file using fstack and gdb demonstrates this fairly  
> > well.)
> >
> > I was wondering what accounts for fstack's ability (or gdb's lack of
> > ability) to do this, and how feasible it would be to migrate this
> > functionality to archer or gdb.
>
> In general, on x86_64 and ia64, for code compiled with any level of
> optimization (and without -fno-omit-frame-pointer) 'core' does not
> have enough info to obtain a stack trace -- you need unwind
> descriptors which are present in the executable.
>
> But on x86, SPARC and PPC, gdb probably could do much better.
> Still, I don't understand what you would do with that info.
>
> Thanks,
> --
> Paul Pluzhnikov