gdb and cores

[Pratheesh]

I am using HP-UX 10.20. While analysing one core file with gdb, I am facing some problems as below.


$ gdb UAM_ControllerMain_0304_preprod -c /home/h10/uamprod/ACTT/core-0417-796834
HP gdb 1.1
Copyright 1986 - 1999 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 1.1 (based on GDB 4.17-hpwdb-980821)
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 10.20.
..

warning: exec file is newer than core file.
Core was generated by `UAM_Controller'.
Program terminated with signal 11, Segmentation fault.
#0
(gdb) shared lib
__dld_list is not valid according to __dld_flags.

(gdb) q
Where UAM_ControllerMain_0304_preprod is our application executable which is linked to several shared libraries.core-0417-796834 is the core file. Can anybody help me why I am not able to analyze the core file with the executable..? Actually the core file has occurred in our production machine which is having the stripped version of the executable.


Regards, Pratheesh

[H.Merijn Brand (procura]

gdb-1.1 is *very* old.

try using to trace the stack with adb, or with a more recent version of gdb

I have a prebuilt gdb-5.2 available in the gcc port for 10.20/pa1.1 on https://www.beepz.com/personal/merijn/ or http://www.cmve.net/~merijn/

Enjoy, have FUN! H.Merijn

[Adam J Markiewicz]

Hi

For me it looks like you've made some updates to your UAM_Controller and recompiled binary.
As gdb wants to confirm that you force it to use appropriate binary with the core it compares some internal checksums, which in this case are different of course.

If these executables (AND the shared libraries) really ARE the same (but only stripped, for example) I have no idea.

Good luck
Adam

[Rick Beldin]

If your binary is one that exec's another one, you need to pass the name of THAT one to gbd. Do a 'file core' to find out the name of the binary.

HP has this situation with the Xserver on PA-RISC 11.x, which consists of a wrapper module which calls another binary. The wrapper makes itself 'look' like X when doing a ps, but the real program is either Xhp or Xf86, depending on the graphics card.