Easy way to debug/read 'core' files.

[Jeffrey Davis_1]

Hi all. What's the most effective (straight line) approach to quickly getting useful info from a 'core' file without spending time trying to step through debugging registers, etc.?
I know of 'strings', but not sure of the value of this pointing to the cause.
I know of 'adb' & 'dde', but am looking for straight forward usage for them. Whithout having to be a programmer.
(N-class, 11.00)
'core' files being generated through Oracle apps. (yes I know I could send it to Oracle support, but it's good to know for ourselves.)
Thanks in advance,

[hpuxrox · Accepted solution]

1. what core
2. file core

[Jeff Schussele]

Hi Jeffrey,

You can use the file command
file core
This will usually at least return the "fault" that generated the dump.

HTH,
Jeff

[Helen French]

Hi Jeffrey:

# file core - can be a starting. You can also use these debug commands: what, gdb, xdb or dde.

Check this document (TKB # KNC071499001) for more information:

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=fabcb16306860f776c/screen=ckiDisplayDocument?docId=200000042264273

HTH,
Shiju

[Jeffrey Davis_1]

Hi, Here is my output from your suggestion.
How can this help me tell the problem?

-rw------- 1 applmgr dba 2287116 Apr 23 09:44 core
# what core
core:
$Revision: 82.3 $
$Revision: 82.8 $
$ PATCH/11.00:PHCO_22314 Sep 30 2000 13:11:34 $ SMART_BIND 92453-07 dld dld dld.sl B.11.19 001014
$ PATHCH/11.00:PHCO_16039 Jul 28 1998 16:05:28
$ STREAMS: Revision: B.11.00 $Date: 99/07/07 14:00:00
$ Pthread Interfaces libpthread HP-UX (Release B.11.00): Tue Aug 31 15:35:32 PDT 1999
HP-UX libm shared PA1.1 C math library 980423 (163456) UX 11.0
$ PATCH/11.00:PHCO_22314 Sep 30 2000 13:11:34 $ SMART_BIND 92453-07 dld dld dld.sl B.11.19 001014

# file core
core: core file from 'more' - received SIGSEGV

[A. Clay Stephenson]

Beyond the file command and strings then this is rather hopeless. You are asking to be able to understand a stack trace without understanding stack traces. In many cases even with debuggers the problem is difficult because the program was not compiled/linked with the debugger data included. Often the symbol table has beem stripped and sometimes even with the debugger/profiler data included the optimizer obscures the actual problem.

You are asking for an easy method that just does not exist. It's a bit like going to a plane crash and wanting to know exactly what caused the crash but not wanting to bother interviewing witnesses and fooling with that silly stuff like flight data recorders.

[hpuxrox]

The error SIGSEGV from the more command could be due to maxtsiz being to low in your kernel.
Try bumping up this value and see if you still core dump.

Peace.......

[Jeffrey Davis_1]

Thanks for all your guidence.
This is what I figured.
I appreciate your advice.
Thanks,

[Bill McNAMARA_1]

To be quite honest Jeff, there is no easy way until the command hey_what_created_you_and_why
is released!

The suggestions above, such as file, will lead you to the app, then apply relevant app patches.

If you really want to debug core, you need to have app source code.

Bill

[Jeff Schussele]

SIGSEGV faults are most often associated with the kernel params maxsiz, maxtsiz & maxdsiz OR _64bit if running 64-bit.
One or all of these may need to be adjusted.
Can also be one/some of the shared memory shm* kernel params as well.
If you will post you kernel params - do
sysdef
here we can take a look at them.

Rgds,
Jeff

[Yogeeraj_1]

Hi,

Just to share my knowledge.

In Oracle normally, each core (cdump directory) is associated with a trace file (bdump directory) more information is also found in alert_.log (bdump)

And of course, you can use "file" on the core dump.

To end, i would say that you should trust the support people (Metalink) they have a good team and do their job well. You might as well ask them questions if something is unclear to you.

with best regards
Yogeeraj