Re: Stack trace from core file without executable

["Paul Pluzhnikov" <ppluzhnikov at google dot com>]

On Mon, Oct 20, 2008 at 6:00 AM, Ray Ruvinskiy <rruvinsk@sybase.com> wrote:

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

And how do you get the library load address?

Assuming you get a crash report from end-user, with core attached,
don't you still have to go back to the user and ask him to find that?

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

A solution which is often used is to ask user to run a
data-collection script before reporting a problem.

The script can collect GDB traces, version and system info, and
whatever else you frequently have to ask user for.

> 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

I note that both of the above stack traces are actually incomplete
(missing the 'raise()' level).

Frysk is probably just walking up the %ebp chain, and so can't give
you correct trace when stepping from VDSO.

> 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 ?? ()

Frame #1 above is correct; I wonder what causes the rest of it to
go wrong :-( ...

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

In any case, given that on several "important" (x86_64 being more
"important" then others :) platforms stack trace from 'core'
without the executable will just not work (TM), it doesn't appear
to be a very worthwhile goal to make this work on platforms where
it may work most of the time.

But if this is important for you, you are certainly welcome to fix
this and send in a patch to gdb-patches@sourceware.org :-)

Cheers,
-- 
Paul Pluzhnikov