This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Stack trace from core file without executable


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
#2 0x0804838a in main() from test
#3 0xb7dbf450 in __libc_start_main() from
#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 < >
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/
#2  0xb7dd5a01 in abort () from /lib/tls/i686/cmov/
#3  0x0804838a in main () at test.c:5

test is:

#include <stdlib.h>

int main()

compiled with:

gcc -g test.o -o test



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

On Sat, Oct 18, 2008 at 2:57 PM, Ray Ruvinskiy <> 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

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.

Paul Pluzhnikov

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]