This is the mail archive of the
mailing list for the Archer project.
Re: Stack trace from core file without executable
On Sun, 19 Oct 2008 17:12:38 +0200, Paul Pluzhnikov wrote:
> On Sun, Oct 19, 2008 at 1:19 AM, Jan Kratochvil
> <firstname.lastname@example.org> wrote:
> > On Sun, 19 Oct 2008 00:19:00 +0200, Paul Pluzhnikov wrote:
> >> 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
> > The maintainers of OOo tell that they are interested only in such program
> > counters chain - no local variables, no parameters. But the core file for
> > these programs is too big to be uploadable from the user. And user even does
> > not have the big debuginfos installed to get the function names.
> So what stops them from either
> - asking the user to run 'gdb -ex "where" OOo core', or
> - doing the same automatically as part of their crash collection?
They do so. I was just making a note the bare "chain of program counters" is
considered as useful by some developers.
> >> 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.
> > I agree. But still one can generate the backtrace anywhere else, just the
> > matching versions of binaries are required.
> Generate the backtrace from what?
> You need the binary and the core *together*. If you do not transfer core
> from end-user system, then you have to generate backtrace on that system,
> don't you? I don't see how build-id helps in that case. What did I miss?
I was talking about debugging crashed OS-distributed binaries, rpm-packaged.
If you know the package version (possibly from the build-id embedded in the
core file) you can download the exact binary the user has yourself from any
public rpms repository.