JDK-8024626 : CTW CRASH: SIGSEGV in ctw/jre/lib/rt_jar/preloading_1 and ctw/jre/lib/rt_jar/sun_awt_X11_ListHelper
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: hs25,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-09-06
  • Updated: 2015-06-04
  • Resolved: 2014-12-03
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.
JDK 8 JDK 9
8u40Fixed 9 b44Fixed
Related Reports
Duplicate :  
JDK-8029394 - sun_awt_X11_MWMConstants segv
Relates :  
JDK-7196866 - CTW fails on all Solaris platforms
Description
These two tests fail:
ctw/jre/lib/rt_jar/preloading_1
ctw/jre/lib/rt_jar/sun_awt_X11_ListHelper

The stack trace looks simliar for both.
Comments
moved from New to Open as an issue from 8_prior_GA (not 8u40)
01-12-2014
Sergey Bylokhov, I reproduced bug on SunOS sparcv9 with latest jdk > ./solaris-sparcv9/bin/java -version Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b40) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-fastdebug-b40, mixed mode) > ./solaris-sparcv9/bin/java -ea -esa -XX:+UnlockDiagnosticVMOptions -XX:+ShowMessageBoxOnError -Xverify:all -XX:+WhiteBoxAPI -XX:+CompileTheWorld -XX:LogFile=hotspot_all.log -Xbootclasspath/p:./solaris-sparcv9/jre/lib/rt.jar According to history this bug occurs only on Solaris.
18-11-2014
Can anyone from SQE help to reproduce this issue? The only thing I can suggest is to use one of the machines it happens on in our nightly testing.
18-11-2014
I cannot reproduce the problem locally. From the stack trace above I see that during MotifDnDConstants initialization the display is 0, it is strange since this class depends from XAtom->XToolkit, and XToolkit class initialize display to non zero value in the headfull environment. If this is a headless environment this class should not be initialized/loaded, in this case we should fail fast. Also we should fail fast if there is some circular dependency, because the correct order of initialization should start from the XToolkit class, this is why a usual client applications are not affected. Command line used: ./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java -ea -esa -XX:+UnlockDiagnosticVMOptions -XX:+ShowMessageBoxOnError -Xverify:all -XX:+WhiteBoxAPI -XX:+CompileTheWorld -XX:LogFile=hotspot_all.log -Xbootclasspath/p:./build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/jre/lib/rt.jar Suggested fix: http://cr.openjdk.java.net/~serb/8024626/webrev.00 But I need a proper steps to reproduce the problem to verify the fix.
17-11-2014
Morris Meyer added a comment - 2014-02-26 12:37 This is not a compiler issue per-se. This SEGV happens because the CTW test individually compiles each class (including the static initializer). The underlying X11 classes need to protect from an out-of-order initialization where XDisplay might be NULL.
11-11-2014
11/11/14 : The issue is on the radar now to re-evaluate
11-11-2014
Are we ever going to fix this one?!?
30-09-2014
Where are we with this one? [~serb], are you working on this?
22-05-2014
This is not a compiler issue per-se. This SEGV happens because the CTW test individually compiles each class (including the static initializer). The underlying X11 classes need to protect from an out-of-order initialization where XDisplay might be NULL.
26-02-2014
You have approval to defer the following issues. Please update. Cheers, B.
07-10-2013
jdk8: SQE OK to defer as it seems to be a bug just in harness code.
30-09-2013
I hope to get this into JDK8. It is not related to the 7196866 fix.
23-09-2013
is it a jdk8 scope? what is expected due date? Morris?
23-09-2013
Sorry about that. Yes, Morris need to look why his 7196866 fix does not work.
11-09-2013
reproduced on jdk8-b106, so it's defently not a SQE problem. moved to client-libs/java.awt $ ./bin/java -version java version "1.8.0-ea-fastdebug" Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b106) Java HotSpot(TM) Server VM (build 25.0-b48-fastdebug, mixed mode)
11-09-2013
Testing problem.
10-09-2013
It is duplicate 7196866 which Morris should have been fixed in jdk8b102.
10-09-2013
Reassigned to compiler team according to Christian's comments above.
09-09-2013
This is an old bug. Vladimir K. knows more about it.
06-09-2013
Stack traces: Stack: [0xfffffd7ffbb7f000,0xfffffd7ffbc7f000], sp=0xfffffd7ffbc7d030, free space=1016k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libX11.so.4+0x532b3] XInternAtom+0x23;; XInternAtom+0x23 C [libawt_xawt.so+0x39a3d] Java_sun_awt_X11_XlibWrapper_InternAtom+0x51;; Java_sun_awt_X11_XlibWrapper_InternAtom+0x51 j sun.awt.X11.XlibWrapper.InternAtom(JLjava/lang/String;I)J+0 j sun.awt.X11.XAtom.<init>(JLjava/lang/String;Z)V+31 j sun.awt.X11.XAtom.<init>(JLjava/lang/String;)V+4 j sun.awt.X11.XAtom.get(Ljava/lang/String;)Lsun/awt/X11/XAtom;+17 j sun.awt.X11.MotifDnDConstants.<clinit>()V+24 v ~StubRoutines::call_stub V [libjvm.so+0x1646ef7] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x14b3;; __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x14b3 V [libjvm.so+0x1645a03] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x3f;; __1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x3f V [libjvm.so+0x13a3c71] void InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x51d;; __1cNInstanceKlassbBcall_class_initializer_impl6FnTinstanceKlassHandle_pnGThread__v_+0x51d V [libjvm.so+0x139a59c] void InstanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xb7c;; __1cNInstanceKlassPinitialize_impl6FnTinstanceKlassHandle_pnGThread__v_+0xb7c V [libjvm.so+0x1397925] void InstanceKlass::initialize(Thread*)+0x85;; __1cNInstanceKlassKinitialize6MpnGThread__v_+0x85 V [libjvm.so+0xf58c38] void ConstantPool::preload_and_initialize_all_classes(ConstantPool*,Thread*)+0x8b8;; __1cMConstantPoolbIpreload_and_initialize_all_classes6Fp0pnGThread__v_+0x8b8 V [libjvm.so+0xd7dba7] void ClassLoader::compile_the_world_in(char*,Handle,Thread*)+0x1ab;; __1cLClassLoaderUcompile_the_world_in6FpcnGHandle_pnGThread__v_+0x1ab V [libjvm.so+0xd7b767] void ClassPathZipEntry::compile_the_world(Handle,Thread*)+0x153;; __1cRClassPathZipEntryRcompile_the_world6MnGHandle_pnGThread__v_+0x153 V [libjvm.so+0xd7c51d] void LazyClassPathEntry::compile_the_world(Handle,Thread*)+0x899;; __1cSLazyClassPathEntryRcompile_the_world6MnGHandle_pnGThread__v_+0x899 V [libjvm.so+0xd7d5d5] void ClassLoader::compile_the_world()+0xfd;; __1cLClassLoaderRcompile_the_world6F_v_+0xfd V [libjvm.so+0x187bab0] JNI_CreateJavaVM+0x238;; JNI_CreateJavaVM+0x238 C [libjli.so+0x9ef1] InitializeJVM+0x109;; InitializeJVM+0x109 C [libjli.so+0x7d98] JavaMain+0x5c;; JavaMain+0x5c C [libc.so.1+0xdd60b] _thr_setup+0x5b;; _thr_setup+0x5b C [libc.so.1+0xdd840] ht_pause+0x10;; _lwp_start+0x0 Stack: [0xfffffd7ffbb7f000,0xfffffd7ffbc7f000], sp=0xfffffd7ffbc7d030, free space=1016k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libX11.so.4+0x532b3] XInternAtom+0x23;; XInternAtom+0x23 C [libawt_xawt.so+0x39a3d] Java_sun_awt_X11_XlibWrapper_InternAtom+0x51;; Java_sun_awt_X11_XlibWrapper_InternAtom+0x51 j sun.awt.X11.XlibWrapper.InternAtom(JLjava/lang/String;I)J+0 j sun.awt.X11.XAtom.<init>(JLjava/lang/String;Z)V+31 j sun.awt.X11.XAtom.<init>(JLjava/lang/String;)V+4 j sun.awt.X11.XAtom.get(Ljava/lang/String;)Lsun/awt/X11/XAtom;+17 j sun.awt.X11.MotifDnDConstants.<clinit>()V+24 v ~StubRoutines::call_stub V [libjvm.so+0x1646ef7] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x14b3;; __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x14b3 V [libjvm.so+0x1645a03] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x3f;; __1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x3f V [libjvm.so+0x13a3c71] void InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x51d;; __1cNInstanceKlassbBcall_class_initializer_impl6FnTinstanceKlassHandle_pnGThread__v_+0x51d V [libjvm.so+0x139a59c] void InstanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xb7c;; __1cNInstanceKlassPinitialize_impl6FnTinstanceKlassHandle_pnGThread__v_+0xb7c V [libjvm.so+0x1397925] void InstanceKlass::initialize(Thread*)+0x85;; __1cNInstanceKlassKinitialize6MpnGThread__v_+0x85 V [libjvm.so+0xf58c38] void ConstantPool::preload_and_initialize_all_classes(ConstantPool*,Thread*)+0x8b8;; __1cMConstantPoolbIpreload_and_initialize_all_classes6Fp0pnGThread__v_+0x8b8 V [libjvm.so+0xd7dba7] void ClassLoader::compile_the_world_in(char*,Handle,Thread*)+0x1ab;; __1cLClassLoaderUcompile_the_world_in6FpcnGHandle_pnGThread__v_+0x1ab V [libjvm.so+0xd7b767] void ClassPathZipEntry::compile_the_world(Handle,Thread*)+0x153;; __1cRClassPathZipEntryRcompile_the_world6MnGHandle_pnGThread__v_+0x153 V [libjvm.so+0xd7c51d] void LazyClassPathEntry::compile_the_world(Handle,Thread*)+0x899;; __1cSLazyClassPathEntryRcompile_the_world6MnGHandle_pnGThread__v_+0x899 V [libjvm.so+0xd7d5d5] void ClassLoader::compile_the_world()+0xfd;; __1cLClassLoaderRcompile_the_world6F_v_+0xfd V [libjvm.so+0x187bab0] JNI_CreateJavaVM+0x238;; JNI_CreateJavaVM+0x238 C [libjli.so+0x9ef1] InitializeJVM+0x109;; InitializeJVM+0x109 C [libjli.so+0x7d98] JavaMain+0x5c;; JavaMain+0x5c C [libc.so.1+0xdd60b] _thr_setup+0x5b;; _thr_setup+0x5b C [libc.so.1+0xdd840] ht_pause+0x10;; _lwp_start+0x0
06-09-2013