Reading COREFILES in HP-UX 11.0

[Muskaan]

Hi all,

I have a corefile from a C++ executable on HP-UX. The only information I can retrieve from the coredump using GDB/WDB is "where"(the coredump occured). What I want to find out is the value of certain variables in one of the calling functions.

This is part of what "where" gives me:

(gdb) where
#0 0xc0183648 in mallinfo () from /lib/libc.2
#1 0xc01860f4 in free () from /lib/libc.2
#2 0x1c958 in TopcomInterface::getData (this=0x400b0720, name=@0x400c9118,
header=0x4007d6e0, buffer=@0x7a0a1210, len=0x7a0a1214)

Looks like it may be trying to free buffer that is not allocated. I want to read the variable "buffer" at location 0x7a0a1210 that u can see stated by gdb above.

Does anyone know how to read corefile and retrieve variable data? Can I read value from a particular memory location ?

What all do I get from the &quot;$ strings -a <corefile>&quot; command?

HELP!!!!

 

[afigona]

well,the strings command will just give you all the readable strings messages in the core file...filtering out the binary junk.

use it piped to &quot;more&quot; or &quot;less&quot;
As for the reading of variable and buffer..i never tried that..i would rather put debug statements in the code itself

 

[Muskaan]

Thanks for your response. I did find out a way to read a mem. locn. in gdb. It is x (remember &quot;examine&quot. So

(gdb) x 0x7a0a1210
would give me the value at that location.

Thought I'd share this find!

Putting debug statements in the code may not help much as the problem occurs in our production instance and that too rarely. So I just have that core file and exe to analyse.

 

[danielhozac]

Printing a variable is done by [tt]p variable[/tt]. //Daniel

 

[DSMARWAY]

hi

see if this helps , this was found on the NET see if it helps your case

If you see a file named &quot;core&quot; lying around and don't know what program
left it there, try the `file' command:

$ file core

This should tell you the program that left the core file. For example:

$ file core
core: core file from 'audio_editor' - received SIGABRT

If by &quot;programmatic core dump&quot; you mean &quot;my program dumped core&quot;, you can use
a good debugger and the sources to get the most thorough answer. Ask the
debugger for a stack trace, which will give you an idea of the routine that
the program was executing when it died.

You can also ask `adb' for a stack trace. To debug an errant program named
`a.out', run adb on a.out and core. Give adb two commands, $C (stack trace)
and $Q (quit). The adb program has no prompt, by the way.

$ PATH=$PATH:/usr/ccs/bin # to get to adb

$ a.out 4 5 6
Floating exception(coredump)

$ adb a.out core
$C
$$divI() from func+1C
func(0) from main+18
data address not found
$Q

The output above shows that when it dumped core, the program was executing a
function named $$divI(), which was called from func(), which was called from
main(). The argument passed to func() was zero. Someone who knows the
sources to the program may be able to interpret the meaning of the argument
or the order of program execution.

This use of adb is documented in the book &quot;The Unix Programming Environment&quot;
by Brian Kernighan and Rob Pike (1984, Prentice-Hall), available in technical
bookstores. Section 6.6, &quot;On bugs and debugging&quot;, starting on page 187, is
especially valuable.