Cannot analyze coredump using shared library

mcm57_at_gmx.at
Date: 06/17/05 

Date: 17 Jun 2005 01:01:30 -0700

Note - Cross-posting: I've posted this question to alt.linux.redhat
yesterday but did not get any hint until now. So please excuse this
crossposting.

-------------------------------------------------------------

I've the problem, that it is not possible to analyse core dump files
using gdb (or ddd which is built on gdb) when the crash (access
violation) occures inside a sahred library.

Details:
Program test is linked with shared library testlib.so. Debugging the
program works normally. All symbols are visible, breakpoints can be set
inside test and testlib etc.

When an access violation (termination signal) occures while executing
code in test a coredump is written. This coredump can be loaded into
gdd and "backtrace" shows sufficient information (after loading the
symbolinformation from image test)

When an access violation (termination signal) occures while executing
code in testlib (the shared library) a coredump is written, too. This
coredump can be loaded into gdd but "backtrace" does not display any
useful information, i.e.

(gdb) backtrace
#0 0xb6873fc6 in ?? ()
#1 0x00000001 in ?? ()
#2 0x00000004 in ?? ()
#3 0x00000001 in ?? ()
#4 0xbfffa758 in ?? ()
#5 0xb755b909 in ?? ()
#6 0x00000001 in ?? ()
#7 0x08048bea in _IO_stdin_used ()
Cannot access memory at address 0x8048b64

I've loaded the symbols from test ("symbol-file test"). But this does
not held. There's a add-symbol-file command. Maybe I have to load the
symbols from the shareable library. But how can I get the name of the
right .so library ? (info share returns "No shared libraries loaded at
this time.") And how can I get the address value required by
add-symbol-file ?

A scan with google did not reveal a solution.

I'm not sure whether this is possible at all. Maybe information cannot
be retrieved per design.
But maybe I missed some commands.
Or I have to set up coredumps different.
Or...

Does anyone suggestions ?

Is there a way to check the contents aof the core dump ?
The main goal for me is to analze WHERE the crash occured,
and if possible to get a traceback stack.

Thanks
Klaus

Relevant Pages

  • Re: Thunderbird 2.0 dumps core on second file open op
    ... My backtrace from the coredump should be in your email box if you still have freebsd-questions from 9:43 EDT this morning... ... I don't know if it's expected behavior or not but the debug version generates quite a few possibly interesting warnings and failed assertion messages to stderr on attaching the first message. ... Another interesting thing is that when saving a received attachment I can do that endlessly, it uses a different dialog though. ...
    (freebsd-questions)
  • Re: =?iso-8859-1?q?Backtrace_von_abgest=FCrzten_Programmen?=
    ... Den Backtrace erhälst Du dann aus dem Coredump, ... Prev by Date: ... Next by Date: ...
    (de.comp.os.unix.linux.misc)
  • Re: panic with tcpdrop
    ... I see you may have a coredump -- could you provide a backtrace from gdb for the below? ... page fault while in kernel mode ...
    (freebsd-current)
  • Network related panic on FreeBSD 5.3-STABLE/AMD64
    ... I can reproduce it easily, ... The panic message and backtrace is: ... I was able to collect a coredump, if it helps, I can make it available ...
    (freebsd-stable)