Core files issues

[gd160...@gmail.com]

An executable crashed on a remote machine, generating a core file.
The program is in C++, 32 bit, running on AIX5.3

Trying to examine it I get -

-bash-3.00# gdb prog core
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "powerpc-ibm-aix5.1.0.0"...

warning: core file may not match specified executable file.
Core was generated by `prog'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000f124 in ?? ()

I also tried with dbx -
root@toucan(aix5.3):dbx prog core
Type 'help' for help.
Core file "core" program "prog" does not match current program
(ignored)

I'm sure the core file did come from the program. Can anyone explain
this and/or suggest a fix?

Thanks!

[Paul Pluzhnikov]

gd160...@gmail.com writes:

> An executable crashed on a remote machine, generating a core file.

In order to analyze core produced by dynamically-linked executable,
debugger needs matching binaries -- both the main executable,
and all the shared libraries that were mapped into it.

Chances are, your libc.a(shr.o) is different from the one on
remote machine.

> Can anyone explain this and/or suggest a fix?

It is probably easiest to just ask remote user to execute a given
set of gdb/dbx commands.

If that's not feasible, as the user to tar up all the remote shared
libraries you expect were in use when the crash happened, untar
them on a local machine, in e.g. /tmp/remote-root/, then use

gdb ./prog
(gdb) set solib-absolute-prefix /tmp/remote-root
(gdb) core core

[Note: solib-absolute-prefix must be set *before* core is loaded.]

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Thomas Braunbeck]

Paul Pluzhnikov schrieb:

>
> If that's not feasible, as the user to tar up all the remote shared
> libraries you expect were in use when the crash happened, untar
> them on a local machine, in e.g. /tmp/remote-root/, then use
>

man snapcore
And to tell dbx where to search for shared objects use the -p flag.