United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6490487 java support on 64 bit solaris x86 machines is broken.
JDK-6490487 : java support on 64 bit solaris x86 machines is broken.

Details
Type:
Bug
Submit Date:
2006-11-06
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2010-06-26
Component:
hotspot
OS:
solaris,solaris_nevada
Sub-Component:
runtime
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
solaris_10,solaris_11,6
Fixed Versions:
hs19 (b03)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description
It isn't clear if this is a pstack bug, a jdk build issue or a hotspot issue. On machines that can run 64bit binaries pstack will attempt to open <jdk>.../client|server/64/libjvm_db.so much like it would on sparc. The hotspot builds in fact create a 64/libjvm_db.so for client and server but they never get copied to the release area. So as a result on 64bit x86 machines libjvm_db.so is never loaded and java frames never get decoded. It is clear if pstack should try to open .../64 first and if that fails then the 32 but version or if the jdk build should copy the .../64 files out to the release area.

                                    

Comments
WORK AROUND

For 32-bit processes use the /usr/bin/i86/pstack instead of /usr/bin/pstack.
The /usr/bin/i86/pstack is a 32-bit version of pstack on 64-bit amd64 machines.
The /usr/bin/pstack     is a 64-bit version of pstack on 64-bit amd64 machines.
                                     
2007-06-28
EVALUATION

For solaris-amd64, it looks like the Hotspot library is correctly exported; it is present at <java_home>/jre/lib/amd64/server/libjvm_db.so.  This is where it should be.  We only use the '64/' directory on sparc -- on x86 the cpu arch is used to determine 32/64 bits (i386 vs. amd64).

> file $JAVA_HOME/jre/lib/amd64/server/libjvm_db.so
/java/east/jdk/7/latest/solaris-amd64/jre/lib/amd64/server/libjvm_db.so:       ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped, no debugging information available

And, it appears that this is where pstack expects to find it (used dtrace to watch what files pstack opened):

> dtrace -q -i 'syscall::open:entry { printf("%s\n", copyinstr(arg0)); }' -c "pstack 13897"

...
/proc/13897/lwp/14/lwpstatus
/net/cocoa/export/jdk/mirror/solaris-amd64/jre/lib/amd64/server/libjvm_db.so
/proc/13897/object/nfs.284.36.23206
/proc/13897/psinfo
/proc/13897/lstatus
/proc/13897/lpsinfo
...

So the library is in the right place, and pstack does find it.  But as the synopsis says -- it's broken!   Needs more investigation to determine where the problem is.
                                     
2007-07-11
EVALUATION

Above comment is valid for 64-bit pstack tracing a 64-bit VM.  For a 32-bit VM, pstack does look for $JAVA_HOME/jre/lib/i386/server/64/libjvm_db.so, which doesn't exist.  So it looks like both a build/RE problem and also some problem with 64/64 pstack/VM.
                                     
2007-07-12
PUBLIC COMMENTS

From 6722157:

I re-discovered this recently on a JDK5 derived product. Building and installing the 64/libjvm_db library was easy enough to do, but having done so it still did not function correctly for me. The Java stack frames were reported as "Interpreter" rather than just a hex value as previously, but the actual java method information is not present.
                                     
2008-11-25
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1747f04ad0c4
                                     
2010-05-26



Hardware and Software, Engineered to Work Together