topic Re: Core file in Operating System - HP-UX

Core file

Omololu — Wed, 04 May 2005 08:08:54 GMT

Is there any other way of analysing a core file generated by an application during an issue on system. CAn Q4 analyse only core file.

How? apart from

# file core

Re: Core file

Florian Heigl (new acc) — Wed, 04 May 2005 08:14:28 GMT

First thing on my mind is adb, but I'm not very skilled with software debuggin, so either look at the man page or wait for more people to reply to see if it suits Your needs.

Re: Core file

Steven E. Protter — Wed, 04 May 2005 08:21:16 GMT

No, q4 analyzes a crash dump.

adb and strings can give you a look at a core file, as can a stack trace.

SEP

Re: Core file

D Block 2 — Wed, 04 May 2005 09:34:55 GMT

adb command:

adb
$c

$q

-- if you are looking for a valid stack trace, then use a real debugger that is free from HP supporting C++ programs named:
WDB.

The problem using "adb" with the $c command, is that, the Stack Trace shows function names as mixed text (mangled). You can not tell a developer which exact member-function caused the core.

You might have to rebuild your executable using a -g option to see the real function-names when running WDB.

When downloading WDB, you will need two packages installed:
1) WDB (which is like GNU's gdb command), and
2) WDB-GUI (which is the Window/Gui package.)

http://www.hp.com/go/wdb

Re: Core file

Amit Agarwal_1 — Wed, 04 May 2005 22:47:27 GMT

You can use gdb to analyse.

$ gdb

Its a fantastic tool to analyse core files. you can use wdb wrapper to get GUI.

Re: Core file

Kent Ostby — Thu, 05 May 2005 04:50:09 GMT

strings is actually not that useful because it will list every possible message that is built into the program or the libraries that it is linked with.

So you will see messages from strings about libdld.sl in almost any core file, but that doesn't mean that libdld.sl has anything to do with the program dying. It just gets linked into a lot of stuff.

adb is useful at times to show the stack trace IF the program was compiled with debugging information mode.

Generally, my approach is to do the "file core" you mention and then talk to the person who wrote the program or load patches if that applies.

If it's a program you wrote, you can look at adb or gdb as possible debugging tools.

Best regards,

Kent M. Ostby

Re: Core file

Doug Burton — Thu, 05 May 2005 05:52:42 GMT

What made the core in the first place:
file core

To get the libs used:
what core

To debug the stinker:
gdb -c core

To debug the stinker:
gdb ProgramName -c core

Also see HP doc - KNC071499001

Re: Core file

Muthukumar_5 — Thu, 05 May 2005 07:04:13 GMT

You can some information from what and then use debugger adb / gdb.

gdb -q
gdb> bt

You will get stack trace by this.

You can also use a simple document as,
http://geocities.com/kmuthu_gct/core_analysis.html

HTH.

Re: Core file

Kent Ostby — Thu, 05 May 2005 08:04:01 GMT

Okay .. found what I was looking for:

echo \$r | adb core

This will tell you where you are in the program and dump the registers.