JDK-6528763 : VM crashes because of something related to LoaderConstraintEntry in 6.0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0u12,5.0u6,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_redhat_3.0,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-02-27
  • Updated: 2012-10-08
  • Resolved: 2007-05-24
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 JDK 7 Other
1.4.2_15,hs10Fixed 6u4Fixed 7Fixed hs10Fixed
Related Reports
Duplicate :  
JDK-6529385 - JVM crashed in LoaderConstraintTable::find_loader_constraint
Relates :  
JDK-6584839 - CheckUnhandledOops flag SEGV's some nsk tests
Description
VM crashes with the attached test case.

Configuration :
  - WindowsXP(SP2, japanese)
  - CPU : Core 2 duo (2.4GHz)
  - Mem : 2GB
  - JDK : 6.0/5.0u11


Reproduce :

 1. Compile *.java and create .jar files (Please see make.csh)

 javac *.java
 jar -cvf base.jar A.class B.class C.class D.class E.class Base.class TestLoader.class
 jar -cvf derived.jar Derived.class TheCompiler.class Launcher.class
 del *.class

 2. Invoke the following command line.(This is described in run_one.csh)
java -client -XX:PermSize=128m -XX:MaxPermSize=128m -Xms256m -Xmx256m -XX:CompileThreshold=2 -cp base.jar TestLoader 1000  "<PATH_TO_JAR>"

ex. 
 If you created derived.jar under D:\users\tbaba\test1.win\derived.jar,
 "<PATH_TO_JAR>" is "file:///D:/users/tbaba/test1.win/derived.jar".
 which is, command line will be
  d:\>java -client -XX:PermSize=128m -XX:MaxPermSize=128m -Xms256m -Xmx256m -XX:CompileThreshold=2 -cp base.jar TestLoader 1000 "file:///D:/users/tbaba/test1.win/derived.jar"


RESULT:

D:\users\tbaba\test1.win>java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode)

D:\users\tbaba\test1.win>java -client -XX:PermSize=128m -XX:MaxPermSize=
128m -Xms256m -Xmx256m -XX:CompileThreshold=2 -cp base.jar TestLoader 1000 "file
:///D:/users/tbaba/test1.win/derived.jar"
Adding  many loader constraints. Please wait....................................
..............
TEST Start!
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d99e672, pid=1860, tid=1572
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-b105 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x12e672]
#
# An error report file with more information is saved as hs_err_pid1860.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

NOTE : 
 - This does not seem to occur single processor.
 - This occurs in Windows, not in Solaris/Linux.
Comments
WORK AROUND Switching from -client to -server, or vice-versa, might avoid the race condition that causes the crash in a given application.
01-03-2007
SUGGESTED FIX *** /tmp/geta16043 Thu Mar 1 16:21:46 2007 --- systemDictionary.cpp Thu Mar 1 15:36:46 2007 *************** *** 2078,2083 **** --- 2078,2084 ---- if (t != T_OBJECT) { klass = Universe::typeArrayKlassObj(t); } else { symbolHandle elem_name(THREAD, object_key); + MutexLocker mu(SystemDictionary_lock, THREAD); klass = constraints()->find_constrained_elem_klass(class_name, elem_name, class_loader, THREAD); } *************** *** 2085,2090 **** --- 2086,2092 ---- klass = Klass::cast(klass)->array_klass_or_null(dimension); } } else { + MutexLocker mu(SystemDictionary_lock, THREAD); // Non-array classes are easy: simply check the constraint table. klass = constraints()->find_constrained_klass(class_name, class_loader); } Edited to show handle being created before taking lock.
01-03-2007
EVALUATION There is a call chain: ciEnv::get_klass_by_name_impl -> SystemDictionary::find_constrained_instance_or_array_klass -> LoaderConstraintTable::find_constrained_klass / elem_klass -> LoaderConstraintTable::find_loader_constraint In this call chain the SystemDictionary lock is NOT acquired. If another thread is extending a constraint, or merging constraints then they may call ensure_loader_constraint_capacity to grow the loader array for a given LoaderConstraintEntry. This will allocate a new array and delete the old one. Hence the execution of find_loader_constraint could iterate an array that has been freed and the memory reused for another purpose.
28-02-2007