In sun solaris whenever a jvm crashes we used to get the core file generated in binary format. We convert this core file to human readable format using
pstack corefile >> log
How can we convert the core file generated in HPUX to human readable format ? We dont have pstack either.
Do you have adb on HP-UX? If so, you could try
adb programfile corefile
$c
$q
That should give you a stack backtrace (syntax from memory and from Solaris, hope I got it right and the syntax is the same).
Yes i have adb. But i fail to understand yr command. I know corefile that got generated. But what is programfile and what is $c and $q ? Can you please give me a more details step by step as I an alien to adb tool you pointed.
programfile is the filename or pathname of the program which generated the core file.
When you start adb, you find yourself in an interactive mode without any prompt 
The first command, $c , prints the stack backtrace. The second command, $q , terminates adb and you'll find yourself at the shell prompt.
That is, if adb on HP-UX works the same, as on Solaris.
So there cannot be a output file generated as shown in the OP ?
How can i find out the
programfile
? All i know is the PID of the JVM.
You can produce an outputfile with:
adb programfile corefile <<EOF >>log
$c
$q
EOF
The file command tells you the program name, but not the path. You might get a clue when you look at the output from ps -ef | grep java when your Java program is running fine. Take into account, that java is a symbolic link in most installations.
Can you tell me the
programfile
from the below output ?
It is /opt/app/d1grn1m1/app1/jdk150_07/bin/IA64N/java .
==> file core
core: ELF-32 core file - IA64 from 'java' - received SIGABRT
Also
See the output below.
==> adb /appl/jdk150_07/bin/IA64N/java core
adb: warning: /usr/lib/hpux32/libcl.so.1: Cannot locate unwind table ...
adb: warning: /usr/lib/hpux32/libcl.so.1: Stack backtrace may fail.
adb> $c
_lwp_kill + 0x30
pthread_kill + 0x9f0
raise + 0xe0
_abort + 0x170
_ZN2os5abortEb + 0x130
_ZN7VMError14report_and_dieEv + 0x4d0
_ZN2os4Hpux22JVM_handle_hpux_signalEiP9__siginfoPvi + 0x5a0
_ZN2os4Hpux13signalHandlerEiP9__siginfoPv + 0x80
adb: error: No load module descriptor for IP '0x0000000031ccf420'.
Now, inorder to convert the whole core file into human readable format you asked me to <<EOF>>.. I'm sorry I dont get what you mean by this. Can you explain in simpler way(Are you asking me to give a logfile name ?? ).
Also as you can see the output above which I am not sure is the desired output because the core dump file is in GBs while the output above is just a few lines. the
file
command shows the format of the core file remained the same. So how did it help ? Am I missing something ?
The EOF-thing is a so called "here-document". This way you can write the input to a command into a shell script. It means
adb programfile corefile <<EOF >>log
Start adb programfile corefile , read the input for the adb-command from the shellscript, until a line is encountered which reads EOF and append the output to the file log
$c
$q
This is the input to the adb-command. The two lines mean: write out the stacktrace and quit
EOF
This ends the here-document. The adb-command will read end-of-file at this point.
I don't know, what you mean with "human readable form". The adb-output is pretty much the same, as the output from pstack.
Based on your inputs find my output below.
==> adb programfile corefile <<EOF >>log
> adb /appl/jdk150_07/bin/IA64N/java core <<EOF >>log
> $c
> $q
> EOF
mymachine:/appl/applogs/PROD_11JUL_Core>
==> ls -ltr
total 7391824
-rw------- 1 bea users 1892292560 Jul 12 11:02 core
-rw-r--r-- 1 bea users 52 Jul 16 03:55 log
So, the log file generated using your guidelines is 52 bytes from the core file 1.9 GB ? I feel the log file generated in human readable form should be much more than 52 bytes. Can you make me understand this ??