Operating System - HP-UX
1753587 Members
7021 Online
108796 Solutions
New Discussion юеВ

Re: java core dump analysis

 
Fedele Giuseppe
Frequent Advisor

java core dump analysis

Hello,

I need to analyse core file generated by a Java application on a remote itanium machine:

file core
core: ELF-32 core file - IA64

I have the core file but I cannot access the remote machine. Moreover I can access to an equivalent machine.

How can I proceed?
Which tool can I use?

Regards
Giuseppe
16 REPLIES 16
Steven E. Protter
Exalted Contributor

Re: java core dump analysis

Shalom Guiseppe,

You might get something to at least look at with the strings command.

That might get you something to search by.

As a precaution, I would insure you have recommended java patches and a current version from http://www.hp.com/go/java

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
kobylka
Valued Contributor

Re: java core dump analysis

Hello Fedele!


On HP-UX you can use wdb or adb for debugging.

WDB is HP's port of GDB for HP-UX, get it here:

http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=cb080f1bace021100f1bace02110275d6e10RCRD


To load the corefile and see where it crashed and why load the executable that produced the crash and the corefile like this:

gdb /path/to/java /path/to/core

or

adb /path/to/java /path/to/core

or, for graphical frontend to gdb,

wdb /path/to/java /path/to/core


for further information consult manpages (man gdb, man wdb, man adb) and online references:

wdb - http://docs.hp.com/en/oshpux11i.html#Debugging%20Tools

gdb - http://dirac.org/linux/gdb/



Beware that if you move the corefile from one system to another you will need Java installed on the target system too (same executable as on source system is strongly encouraged).


Kind regards,

Kobylka
Fedele Giuseppe
Frequent Advisor

Re: java core dump analysis

Hello,

if I run the command:

# /opt/langtools/bin/gdb64 /opt/java1.5/jre/bin/java /usr/Systems/HA_9.1.0_Master/core

I obtain the following output:

Detected 32-bit executable.
Invoking /usr/ccs/bin/gdb32.
HP gdb 5.9 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.9 (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 file is in different format from executable
To unload the executable use the "file" command with no argument

(gdb)

What does the last message means ("Core file is in different format from executable
To unload the executable use the "file" command with no argument") ?

Can I proceed? And in which way?

Giuseppe

kobylka
Valued Contributor

Re: java core dump analysis

Hello Fedele!

Seems like you are on a PA-RISC based machine:

> HP gdb 5.9 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00


trying to load a corefile from an Itanium executable:

> Core file is in different format from executable


1. First you need to get on an Itanium based machine with gdb/wdb installed.

2. Then you need to find the executable for the corefile. If you are sure the corefile was generated by Java then run gdb with the java executable as you did in the last post (but on Itanium).

Just to be sure the corefile was generated by the java executable try this:

gdb -core /usr/Systems/HA_9.1.0_Master/core

It should print a line like this:

"Core generated by executable_name"


When you found the needed executable it should load fine so you can do a backtrace.

Kind regards,

Kobylka

Dennis Handly
Acclaimed Contributor

Re: java core dump analysis

> I need to analyse core file generated by a Java

What do you expect to find?

>/opt/langtools/bin/gdb64 /opt/java1.5/jre/bin/java

This is the wrong java. This PA one is the driver and immediately execs the real one in:
/opt/java1.5/jre/bin/IA64N/java
/opt/java1.5/jre/bin/IA64W/java

>Kobylka: Beware that if you move the corefile from one system to another you will need Java installed on the target system too (same executable as on source system is strongly encouraged).

Don't even bother doing this unless you use the packcore command to copy ALL of the files.
Fedele Giuseppe
Frequent Advisor

Re: java core dump analysis

Hi Kobylka, hi Dennis,

first of all I made a mistake: I had installed WDB PA-RISC version on an ITANIUM machine.

Now I have installed WDB 5.9 + patch PHSS_38157 on my ITANIUM machine.

If I try to check my core file as you have suggested, I obtain the following error:

trhpli,sys,root # gdb -core ./core
HP gdb 5.9 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.9 (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.


warning: Unknown symbols for './core'; use the 'symbol-file' command.

Couldn't fetch registers from core file: File in wrong format
No object file symbols.
Couldn't fetch registers from core file: File in wrong format
Couldn't fetch registers from core file: File in wrong format

warning: Unable to read the load_info structure address from .
#0 0x0 in ()

How can I proceed?

Thanks

Giuseppe
kobylka
Valued Contributor

Re: java core dump analysis

Hello Fedele!

Seems gdb doesn't handle -core behaviour on cross debugging.


Ok, basically you need the executable which generated the corefile. Since you cannot access the machine where the corefile is from, but you know it is a java corefile you need to install the correct JDK/JRE in order to get the "java" executable. Do you remember what JDK/JRE version was installed on the machine you can't access?

If yes, install the corresponding version from
https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXJAVAHOME

If not, try this to narrow down the possibilities:

strings -n 3 core | more

and look for a string like:

PATH=...

this could give you the path where the java executable was from if it was executed on command line.

Furthermore, watch out for strings like, for example, ./java or /opt/java1.5/bin/java.


Kind regards,

Kobylka


Dennis: I owe you a response to your post :)
Fedele Giuseppe
Frequent Advisor

Re: java core dump analysis

Hi,

by executing:
strings -n 3 ./core | grep java | grep bin

I get:

/opt/java1.5/jre/bin/IA64N/java

that is the same installed on my machine:

-r-xr-xr-x 1 bin bin 236912 Mar 9 2009 /opt/java1.5/jre/bin/IA64N/java

Giuseppe
kobylka
Valued Contributor

Re: java core dump analysis

Hi!


Try to load it into gdb:

# gdb /opt/java1.5/jre/bin/IA64N/java /path/to/core



The only problem I see is there are several versions of Java 1.5 (JDK or JRE):

https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXJDKJRE50

if your local version doesn't match exactly your corefile's version then there could be errors running gdb.


Kind regards,

Kobylka