how to analyze "core"?

[whuijun_1]

my system:HPUX11.00 HP 9000

I found the system sometimes produce one or more very large core file(s).

I want to find out the reason.could you help me?
thanks a lot.

[Elmar P. Kolkman]

Running the file command on the core file gives some info, for instance which command generated the core file and why, for instance because of an abort, segmentation fault, etc.

To get more info out of the corefile you could try some debuggers like adb, gdb, etc. if you have them. Depending on the way the executable was compiled you get more or less info...

[John Carr_2]

Hi

you can use the command q4 to do an analysis of the core file too.

:-) John.

[Fabio Ettore]

Hi,

to analyze core file on HP-UX systems there are two tools, adb and Q4. They are two debuggers.
For manpage of adb just type man adb, for manpage of Q4 type

# cd /usr/contrib/doc
# uncompress Q4Docs.tar.Z
# tar xvf Q4Docs.tar

I hope this helps you.

Best regards,
Ettore

[whuijun_1]

q4? good idea!

could you supply me a real solution?

[whuijun_1]

sorry John,I misunderstood you.

hi, everyone,could you tell me how to avoid produing core files?

thanks again.

[Umapathy S]

file and gdb will be a good choice. With q4, you wont be able to understand the problem. The output of the q4 needs to be send to hp and they will analyze the problem. Normally it is done for kernel core dumps.

First identify which one is dumping core by the file command.

There is seperate document for q4 analysis also. Not able to connect to the knowledge base.

HTH,
Umapathy

[Elmar P. Kolkman]

1) closing the directories so the corefiles can not be created
2) kill applications in ways that don't produce core files
3) you could take a look at this link: http://groups.google.nl/groups?q=core+size+hp-ux&hl=nl&lr=&ie=UTF-8&selm=CYRIL.95Mar8193806%40cli53wy.der.edf.fr&rnum=1

Good luck. Elmar

[Dwyane Everts_1]

Whuijin,

All the tools mentioned seem like good ideas, but I generally perform the command:

strings core | more

This pulls all the data strings from your core file and displays them. Usually, you can determine the application that caused the problem, and sometimes the process that failed. But it generally gives you a great place to start troubleshooting.

As for stopping the creation of a core file...why? Core files tell you when something is seriously broken. Why hide the fact that something is broken? Fix it. I have a script that runs once each morning (just before I come in) that searches for core files, notifies me, and gives me a headups as to what needs fixed. (just an idea.)

D

[Paula J Frazer-Campbell]

Hi
To analyze core files

file
what
Strings

Also

Down load and install wdb:-

http://hp.com/go/wdb

fire up /opt/langtools/bin/gdb -c
"bt" will give a stack trace:-

(gdb) bt
#0 0xc01ecb88 in ??
#1 0xc01ecb68 in ?? ()
#2 0xc01ecb68 in ?? ()

or use "where"

There are two stored registers that will tell you the address being
accessed
and instruction the process was executing when it failed. In gdb or at
the
"(gdb)" command prompt in wdb, try:

(gdb) p /x $ior

This prints the "Interrupt Offset Register" that is the address the
program was trying to access when it failed.

(gdb) p /x $iir

This is the "Interrupt Instruction Register" that shows the machine instruction that caused the failure. To decode this start up a separate "adb" (adb) should already be installed ??? note it has no prompt and the $ prefixes each command - $q = quit) session and enter the value from the above command and follow it
with "=i". For example,

(gdb) p /x $iir
$2 = 0xfe01280

$ adb
0xfe01280=i
LDW 254,0(r31)
This is a Load word command being executed. See instructions set for PA Risc.

HTH

Paula

[Bill Hassell]

All of the debug information is useful if the program that is producing the core file is under your control (ie, you have the source code, compilers and debuggers and skill to fix it). If the core file is from an HP-UX process, then you'll need to call HP support or search through the ITRC patches to see if there is a fix. Knowing the reason for a program crash won't help much if you can't fix the original code.

[Mark Greene_1]

To stop users from producing core files, add this to their .profile:

ulimit -c 0

mark

[ranganath ramachandra]

please do not use 'strings' on a core file. it can lead to more confusions than solutions. there are other tools (file, what, size, adb, q4, gdb, chatr, elfdump/odump etc) that give you more specific information.

[whuijun_2]

Hi,guys,

anyway,thanks for your help:-)