GDB : trace back

[Shameem Arakkal]

I am trying to find the point in the code at which the program went down. Using gdb on the
core file, a bt/where/info stack command doesn't trace back to any line in the code. A bt gives me the following:

(gdb) bt
#0 0xc0183364 in mallinfo()from /usr/lib/libc.2
#1 0xc0185dd4 in free () from /usr/lib/libc.2
#2 0xc02a45a8 in __rethrow () from /usr/lib/libCsup.2
(gdb)

The above shows the stack frame for the libraries only and not for the code. Can anyone tell me how I can trace back to the point in the code at which the core dump occured?

I would also like to add that the core file was generated in a different HP-UX box. Since
that box didn't have a gdb, I ported it over to our development box and did my debugging
there. Both the boxes though have same configuration (HP-UX 11.0)

When I start the gdb with the core file, I get the following:

> gdb orbadatopS core
HP gdb 2.1
Copyright 1986 - 1999 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 2.1 (based on GDB 5.0-hpwdb-20000630)
Wildebeest is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under certain
conditions. Type "show copying" to see the conditions. There is
absolutely no warranty for Wildebeest. Type "show warranty" for details.
Wildebeest was built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00.
..
Core was generated by `orbadatopS'.
Program terminated with signal 11, Segmentation fault.

warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.


warning: Can't find file /home/sam/ytop/bin/orbadatopS referenced in dld_list.

warning: Can't find file /opt/iona/lib/liborbixmt.3.0.1.aCC.A.03.13.1 referenced in

dld_list.

warning: Can't find file /opt/iona/lib/libITtlsmt.3.0.1.aCC.A.03.13.1 referenced in

dld_list.

warning: Can't find file /opt/topcom/TOPCOM_5.5.41/til/libtil.sl referenced in dld_list.
#0 0xc0183364 in mallinfo () from /usr/lib/libc.2

[Paula J Frazer-Campbell]

Hi
Analysis of core files should be done on the machine on which they occured.

GDB and ADB are tool to use in conjunction with the software that caused the core file.

GDB/ADB will assist but will not say "fault occured at a particular line number.


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