JDK-6323299 : VM crashes if JRE is run from network disk
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-09-13
  • Updated: 2012-10-08
  • Resolved: 2006-02-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u10Fixed 6 b71Fixed
Related Reports
Relates :  
Relates :  
Description
J2SE	       : FAIL - mustang b50, b51
                 PASS - mustang b49
Platform[s]    : FAIL - Solaris x86
switch/Mode    : FAIL - default

VM crashes if JavaTest application is run using JRE from network drive. This failure is 100% reproducible. Same JRE copied to local drive works Ok. There are no troubles accessing remote drive. Please find core and hs_err_pid attached. This machine was patched with Solaris recommended patch cluster today. Crash was also occuring before patching.

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xd2dac1c3, pid=953, tid=1
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b50 mixed mode, sharing)
# Problematic frame:
# V  [libjvm.so+0x2ac1c3]
#
# An error report file with more information is saved as hs_err_pid953.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Specific Machine Info (located out of SWAN in SPB, Russia):
=====================
[stt-robot@stt-11]~$ uname -a
SunOS stt-11 5.10 Generic i86pc i386 i86pc

[stt-robot@stt-11]~$ df -k /set/stt/jdk_promotions/
Filesystem            kbytes    used   avail capacity  Mounted on
stt-26:/export/stt   58336125 38247247 19505517    67%    /set/stt
[stt-robot@stt-11]~$ 

[stt-robot@stt-26]~$ uname -a
SunOS stt-26 5.9 Generic_117172-07 i86pc i386 i86pc
[stt-robot@stt-26]~$ 

[stt-robot@stt-26]~$ share
-               /export/stt   rw   "/set/stt" 
[stt-robot@stt-26]~$ 


How To Reproduce (SPB specific)
=====================
#!/bin/bash

HARNESS_JDK="/tmp/b50/solaris-i586/jre1.6.0"
# HARNESS_JDK="/set/stt/jdk_promotions/JDK6.0/b50/binaries/solaris-i586/jre1.6.0"

HARNESS_OPTIONS="-Xmx150m -Djavatest.maxOutputSize=1000000"
HARNESS_PATH="/tmp/b44"

export DISPLAY=stt-11:0

"$HARNESS_JDK/bin/java" $HARNESS_OPTIONS -cp "$HARNESS_PATH/javatest.jar" \
    -showversion \
    com.sun.javatest.tool.Main -newDesktop


In SWAN javatest.jar can be found in /net/jre.sfbay/p/v10/jck/6.0/beta/b06/binaries/JCK-runtime-60/lib/javatest.jar

Comments
EVALUATION It was an interesting Solaris only bug (in fact any platform where large pages is default). If we use large pages, GC sometimes doesn't obey page alignment, and thus when mapping shared archive into address space our computations of proper heap locations fail, due requirment of page alignment of permanent generation. -Xmx option with client compiler can turn on/off large pages, and thus hide or reveal this bug. Fix is to make sure large page size is considered, during proper alignment computations, and also never turn off large pages during shared archive generation.
23-01-2006

WORK AROUND -Xshare:off will disable sharing and help workaround this crash.
08-12-2005