Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines (original) (raw)

Phil Race philip.race at oracle.com
Wed Feb 12 10:32:44 PST 2014

The README-builds.html file specifies SS12 Update 1 + a bunch of patches There's probably a good reason for all of that and new architectures often need compiler fixes, so does the same occur if you upgrade and patch ?

-phil.

On 2/12/2014 7:48 AM, Baesken, Matthias wrote:

I noticed when building Open JDK 8 fast-debug with Sun Studio 12 on Solaris Sparc, the VM crashes early when executed on T4 based machines (both T4 based Solaris Sparc10 and 11 machines); I cannot see the issue on older Sparc processors or Fujitsu SPARC64. The Crashes look like this :

/results/SS12/images/j2sdk-image/bin/java -version # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/jni.cpp:278 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/net/usr.work/d040975/openjdk/jdk82/hotspot/src/share/vm/prims/jni.cpp:278), pid=27252, tid=2 # guarantee(klasshashok(k, id)) failed: Bug in native code: jfieldID class must match object # # JRE version: (8.0) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.0-b69-fastdebug mixed mode solaris-sparc compressed oops) # Core dump written. Default location: //core or core.27252 # # An error report file with more information is saved as: # //hserrpid27252.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 2 Dumping core ... Abort (core dumped) With Stack in the hserr file : --------------- T H R E A D --------------- Current thread (0x0000000100111800): JavaThread "main" [threadinvm, id=2, stack(0xffffffff7e200000,0xffffffff7e300000)] Stack: [0xffffffff7e200000,0xffffffff7e300000], sp=0xffffffff7e2fdd50, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xfc8824] void VMError::reportanddie()+0x504 V [libjvm.so+0x66ee70] void reportvmerror(const char*,int,const char*,const char*)+0x78 V [libjvm.so+0x925798] void jfieldIDWorkaround::verifyinstancejfieldID(Klass*,jfieldID*)+0xa8 V [libjvm.so+0x8f07a8] jfieldIDjfieldIDWorkaround::toinstancejfieldID(Klass,int)+0x60 V [libjvm.so+0x953b8c] jniGetFieldID+0x52c C [libjava.so+0xe46c] JavajavaioFileInputStreaminitIDs+0x44 j java.io.FileInputStream.initIDs()V+-373565320 j java.io.FileInputStream.initIDs()V+0 j java.io.FileInputStream.()V+0 v ~StubRoutines::callstub V [libjvm.so+0x8fe0bc] void JavaCalls::callhelper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 V [libjvm.so+0x82daac] void InstanceKlass::callclassinitializerimpl(instanceKlassHandle,Thread*)+0x224 V [libjvm.so+0x82d7f8] void InstanceKlass::callclassinitializer(Thread*)+0x24 V [libjvm.so+0x82c260] void InstanceKlass::initializeimpl(instanceKlassHandle,Thread*)+0xb08 V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c V [libjvm.so+0x8dad34] void InterpreterRuntime::new(JavaThread*,ConstantPool*,int)+0x254 j java.lang.System.initializeSystemClass()V+37 v ~StubRoutines::callstub V [libjvm.so+0x8fe0bc] void JavaCalls::callhelper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 V [libjvm.so+0x8fd31c] void JavaCalls::callstatic(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104 V [libjvm.so+0x8fd8bc] void JavaCalls::callstatic(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64 V [libjvm.so+0xf27f80] void callinitializeSystemClass(Thread*)+0x80 V [libjvm.so+0xf3317c] int Threads::createvm(JavaVMInitArgs*,bool*)+0x76c V [libjvm.so+0x9772ec] JNICreateJavaVM+0xe4 C [libjli.so+0x7d9c] InitializeJVM+0x104 C [libjli.so+0x6220] JavaMain+0x68

When building with Sun Studio 12u1 (instead of 12) the crash does not occur, see : /results/SS12u1/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-d040975201402121529-b00) OpenJDK 64-Bit Server VM (build 25.0-b69-fastdebug, mixed mode) Is this a known issue with SunStudio12 build results on T4 Processors ? I changed the used optimization flags in the fast-debug build from -xO4 to -xO2 and the problem disappeared. Could this be done in the configuration when SunStudio 12 is detected ? Thanks, Matthias

More information about the hotspot-dev mailing list