Re: collecting "oobs" message for user applications (WAS: Re: stack trace without core)

On Jun 24, 12:44 pm, David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
On Jun 23, 11:43 pm,RezaRob<Reza...@xxxxxxxxx> wrote:

If I just dump the stack, is there any way to tell gdb to reconstruct
the thing after the fact? For instance, can gcc generate a separate
file similar to the "system.map" file that the kernel uses?

I don't see what you would want 'gdb' for at that point. If you must
do it that way, just write the stack to a file using
__builtin_return_address. It may help to also write out a well-known
address in case the executable has been relocated. You can them
compare those addresses to a symbol table.

Good point about relocation :-) If it helps solve such a potential
issue it's great.


Compile/link the executable with symbols. Run 'nm' on the executable
and save the output. Then strip and ship. If you get a dump file, just
compare the addresses in the file to the ones in your 'nm' output.

I wanted a stack dump + gdb solution, because that can also give me
_some_ idea about the specific function parameters that initiated the
crash. This can help greatly with debugging, and acts more similar to
a kernel oobs, i.e. a very brief "snapshot" of what was happening,
without the disturbing noise.


Are you shipping a dynamically-linked or a statically-linked
executable? If dynamically-linked, I would still try to 'dlsym' the
addresses, because if they're in a library on that user's machine,
your symbol table won't help you -- you need the symbol table for the
library on the customer's machine.

I'm not concerned about the user's library being buggy. "gdb" or
whatever can just give me a raw address for unknown symbols, as long
as I can get the general pattern of what _my_ code was up to at the
time. So that it gives me a starting point to think about :-)

Thanks again.

Reza.

.

Relevant Pages

  • Re: problems debugging panic with gdb, kdump, and vmcore
    ... I've got a kernel panic that is easily reproducible (I am 99% sure ... but trying to use gdb on it gives very strange results. ... # CPUFreq processor drivers ... # SCSI device support ...
    (Linux-Kernel)
  • [2.6 patch] move frv docs one level up
    ... A summary of the configuration options particular to this architecture. ... A description of how to boot the kernel image and a summary of the kernel ... An example .gdbinit file for use with GDB. ... A description of the CPU clock scaling interface. ...
    (Linux-Kernel)
  • Re: oops in :snd_pcm_oss:resample_expand+0x19c/0x1f0
    ... Thanks for trying out kdump. ... For example, the small script you wrote for saving the dump, is already ... "service kdump start" and initrd will be generated and kdump kernel will ... Currently we can use gdb but only for linearly mapped region. ...
    (Linux-Kernel)
  • problems debugging panic with gdb, kdump, and vmcore
    ... I've got a kernel panic that is easily reproducible (I am 99% sure ... but trying to use gdb on it gives very strange results. ... # CPUFreq processor drivers ... # SCSI device support ...
    (Linux-Kernel)
  • Re: Firewire blues
    ... I compiled a kernel with exactly the same options that you cited below. ... it entering the debugger and waiting for the remote gdb attach. ... When I try to attach from the debug machine, ...
    (freebsd-hackers)