Core file Analysis

[prajakta]

Hi

I have core with me,

This is wat the core shows with the gdb cmd, I need to know whether the core is analysed with the correct version of GDB or the core is corrupted.

HP gdb 5.2 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00
and target hppa1.1-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.2 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `Hpux_xyz'.
Program terminated with signal 11, Segmentation fault.
Unknown si_code. Report to HP.
#0 0xc01700d4 in ()
(gdb) where
#0 0xc01700d4 in ()
warning: Attempting to unwind past bad PC 0xc01700d4
#1 0xcc410278 in ()
(gdb) bt
#0 0xc01700d4 in ()
#1 0xcc410278 in ()
(gdb)

because i did't get the sufficint information from the core analysis.

[Matti_Kurkela]

What's the HP-UX version of the system that produced the core? Does that system have a PA-RISC CPU, or an Itanium?

If it's newer than 11.00, the gdb of HP-UX 11.00 might not understand all the information in the core file.

The "si_code" would give more detailed information about the cause of the signal that interrupted the program. In this case, gdb does not know what the si_code of this particular core file means.

MK

[Dennis Handly]

Are you on 11i? If so, the latest version is 5.7:
http://www.hp.com/go/wdb

Are you are the exact same system that created the core file?
If not, you must use the packcore command to package up everything when you move to another system.

What was your gdb command line?

Core was generated by `Hpux_xyz'.
Program terminated with signal 11, Segmentation fault.
Unknown si_code.
#0 0xc01700d4 in

This basically says you got signal 11 in some shlib and it can't figure that out. Does "info shared" show anything?

>MK: Does that system have a PA-RISC CPU, or an Itanium?

This was given in the gdb banner.

>The "si_code" would give more detailed information about the cause of the signal that interrupted the program.

That isn't all that important. All signal 10s and 11s are really the same thing. You have to decode it by looking at the PC, instructions and registers.

>gdb does not know what the si_code of this particular core file means.

It may be that old gdb doesn't know about any si_codes. In any case, that gdb error recovery is bogus. It should print the number if it can't decode it.