Core files

[Jorge Prado T]

Hi,

whereupon tool can be read and be analyzed the Core files?
S.O.= hpux 11i

Thank in advance

Jorge Prado

[A. Clay Stephenson]

The tool is gdb.

[Stuart Abramson]

I've never had any luck reading core files. I just erase them.

If it recurrs, send it to the HP Response Center with a ticket.

[John Kittel]

I think Mr. Stehpenson probably meant "adb".

- John

[John Kittel]

Sorry, I guess I should have looked BEFORE I replied. There is a gdb. I didn't know that before.

[A. Clay Stephenson]

Luck has nothing to do with reading core files but knowledge does. The most common operation is a stack trace. Unfortunately, unless the program were compiled to include the debugging infomation then tracing is much more difficult because now rather than dealing with meaningful symbols (e.g. my_function, my_int_var) you have hex addresses.

Meaning absolutely no insult, if one doesn't even know the name of the tool(s) used to examine core files then it's highly doubtful than one has the expertise to know what one is examining.

[Amit Agarwal_1]

As said by Clay, gdb is the tool to debug core files. If you have the expertise or if willing to learn you can use gdb even to the extent where you can trace down to the intruction and variable causing the core dump.

If it is in-house application(you have the source code), try compiling with -g option and then reproduce the core file. Use source code, app and core with gdb to find the stack trace, the current values of local variables, and all. By looking at the hex address, you can know the instruction causing the coredump.

In case you don't have the source code, or you don't want to recpompile, or debuggable app does not core dump, you can still work with the original application. The differnce being that now you have to understand the assembly instructions and then figure out the last instruction. Using the register names and with the understanding of HP-UX runtime env, you can trace the variable causing the issue.

Having said all this, its not necessary that you will be successful everytime, but there is a lot information in the core file to guide you in the right direction.

Regards,
Amit

[vinod_25 · Accepted solution]

hi jorge

Use one of the program debuggers to create the additional information: gdb, xdb, or dde.

Determine the program that is generating the core
For eg:
file core
core: core file from 'dtcalc' - received SIGABRT

The default location all of these tools is
/opt/langtools/bin.

a. gdb (Gnu Debugger)
eg: gdb -xdb /usr/dt/bin/dtcalc core

b. dde - HP/DDE debugger
eg: dde -ui line core /usr/dt/bin/dtcalc

c. xdb
eg: xdb -l ALL /usr/dt/bin/dtcalc core


Regards

Vinod K

[Kalim Jacobs]

Suppose the core file is a product of a TK or tcl script. Is there a way to debug core files? Can I at elast find the reason for core to dump - like out of resources, attempt to write to closed port, etc. ?

/opt/langtools/bin/dde -ui line core ./Q
?(dbgk_hpux_pa) File './Q' is not of a known object file type.
(Perhaps the file is a shell script?)
?(dbgk_hpux_pa) File '/sysval/iapa_poi/tools/svs/core' is not of a known object file type.
(Perhaps the file is a shell script?)
?(dde) Target program load of "/sysval/iapa_poi/tools/svs/core" failed

[Kalim Jacobs]

I got it. Point to the executable instead of the script. Typically the script tells you the executable at the top:

#!/usr/local/bin/wish -f


jacobs@hueco [/sysval/iapa_poi/tools/svs]% /opt/langtools/bin/dde -ui line core /usr/local/bin/wish