JDK-8068646 : nsk/stress/metaspace/jck60/jck60013 crash with SIGBUS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-01-08
  • Updated: 2015-01-22
  • Resolved: 2015-01-22
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 9
9Resolved
Related Reports
Duplicate :  
Relates :  
Description
 -----------------  lwp# 277 / thread# 277  --------------------
 0000000000000000 ???????? (ffffffff2e0fbae0, ffffffb076707b3b, ffffffb074e00000, ffffffb076d76568, ffffffb0760bdf90, ffffffb076e372a0) + 855de628
 ffffffb07593d98c __1cFframeNprint_C_frame6FpnMoutputStream_pcipC_v_ (ffffffff2e0fbae0, ffffffb076e7d138, 7d0, ffffffb07607b7c0, ffffffff2e0fb850, ffffffb076707b5a) + 3c
 ffffffb0763ec408 __1cHVMErrorGreport6MpnMoutputStream__v_ (ffffffff2e0fbc28, ffffffff2e0fbae0, ffffffb076bf1529, ffffffb076bf1585, ffffffb076e42d3c, ffffffb076b7ab9d) + 5f8
 ffffffb0763ed97c __1cHVMErrorOreport_and_die6M_v_ (ffffffff2e0fbc28, db540, db400, 3c00, 1fac00, ffffffb076e51a18) + 37c
 ffffffb0760b81a4 JVM_handle_solaris_signal (a, ffffffff2e0fc3b0, c0800, ffffffff2e0fbc28, ffffffff2e0fc0d0, 103641000) + c6c
 ffffffb0760b0264 signalHandler (a, ffffffff2e0fc3b0, ffffffff2e0fc0d0, 0, 0, 0) + 1c
 ffffffff7eee26ac __sighndlr (a, ffffffff2e0fc3b0, ffffffff2e0fc0d0, ffffffb0760b0248, 0, ffffffff7f07e000) + c
 ffffffff7eed5ce0 call_user_handler (ffffffff34619a40, ffffffff2e0fc3b0, ffbffeff, 0, 0, a) + 364
 ffffffff7eed5f10 sigacthandler (a, ffffffff2e0fc3b0, ffffffff2e0fc0d0, 1a8148, ffffffff7f07e000, a) + 5c
 --- called from signal handler with signal 10 (SIGBUS) ---
 ffffffb07607b7c0 __1cNObjectMonitorGEnterI6MpnGThread__v_ (102caba00, 103641000, 200, bc90c, ffffffb076d76568, ffffffb0769fc53d) + 520
 ffffffb07607ac7c __1cNObjectMonitorFenter6MpnGThread__v_ (102caba00, 103641000, 3, ffffffb076e001d7, ffffffb076d76568, ffffffb0769fb925) + 5b4
 ffffffb0762cb9e0 __1cSObjectSynchronizerKslow_enter6FnGHandle_pnJBasicLock_pnGThread__v_ (102caba02, ffffffff2e0fcd50, 103641000, ffffffb076b136d8, 3, ffffffb076d76568) + 300
 ffffffb0762cb404 __1cSObjectSynchronizerKfast_enter6FnGHandle_pnJBasicLock_bpnGThread__v_ (102caba02, ffffffff2e0fcd50, 7dc0c9e20, 103641000, ffffffb076e001d7, 5a800) + 194
 ffffffb075653ecc __1cIRuntime1Mmonitorenter6FpnKJavaThread_pnHoopDesc_pnPBasicObjectLock__v_ (103641000, 7dc0c9e20, ffffffff2e0fcd50, 310e, ffffffb07657d5fd, ffffffb076d76568) + 414
 ffffffff68481aec * monitorenter_nofpu Runtime1 stub
 ffffffff68d1b99c * java/io/PrintWriter.print(C)V+25256
 ffffffff68008858 * java/io/PrintWriter.print(C)V+2
 ffffffff68008858 * javasoft/sqe/tests/api/java/io/Serialization/ObjectOutputStream/DumpOutputStream.flush()V+138
 ffffffff68008858 * javasoft/sqe/tests/api/java/io/Serialization/ObjectOutputStream/DumpOutputStream.write(I)V+32
 ffffffff6feddb78 ???????? (7f4438338, 7dc19ec90, 0, d3, 0, ffffffb076e001d7) + fffffffff54bc1a0
 ffffffff68e0ac84 * javasoft/sqe/tests/api/java/io/Serialization/ObjectOutputStream/PrimitivesTest.run([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Ljavasoft/sqe/javatest/Status;+6110
 ffffffff68008858 * javasoft/sqe/tests/api/java/io/Serialization/ObjectOutputStream/PrimitivesTest.run([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Ljavasoft/sqe/javatest/Status;+154
 ffffffff6800053c * StubRoutines (1)
 ffffffb075b84b40 __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (ffffffff2e0fe368, ffffffb076e404a8, ffffffff652d8b88, 0, 103641008, 4) + 950
 ffffffb0761abb0c __1cKReflectionGinvoke6FnTinstanceKlassHandle_nMmethodHandle_nGHandle_bnOobjArrayHandle_nJBasicType_4bpnGThread__nDoop__ (0, 103641000, ffffffff2e0fe350, c, 4, ffffffff2e0fe3c8) + 2874
 ffffffb0761ac9c4 __1cKReflectionNinvoke_method6FnDoop_nGHandle_nOobjArrayHandle_pnGThread__1_ (ffffffff2e0fea70, c, 103642260, 1, 103641000, 3d68) + 6ec
 ffffffb075d10d1c JVM_InvokeMethod (103641240, ffffffff2e0fea78, ffffffff2e0fea80, ffffffff2e0fea68, ffffffff2e0fea90, ffffffff2e0fea70) + 4a4
 ffffffb074a16450 Java_sun_reflect_NativeMethodAccessorImpl_invoke0 (103641240, ffffffff2e0fec78, ffffffff2e0fec48, ffffffff2e0fec50, ffffffff2e0fec58, 0) + 10
 ffffffff6fd0cb70 * sun/reflect/NativeMethodAccessorImpl.<init>(Ljava/lang/reflect/Method;)V+27464
 ffffffff6800870c * sun/reflect/NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100
 ffffffff6fd0c228 ???????? (7f67fca00, 7dc137b80, 7f67fc9c8, ffffffb076dff881, 0, ffffffb076e001d7) + fffffffff52ea850
 ffffffff68d628fc * nsk/stress/share/MetaspaceTestRunner$TestThread.run()V+-28000
 ffffffff6800870c * nsk/stress/share/MetaspaceTestRunner$TestThread.run()V+226
 ffffffff6800053c * StubRoutines (1)
 ffffffb075b84b40 __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (ffffffff2e0ff968, ffffffb076e404a8, ffffffff65126860, 0, 103641008, 1) + 950
 ffffffb075b832b0 __1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_pnGSymbol_5pnRJavaCallArguments_pnGThread__v_ (ffffffff2e0ff968, 89c00, 7fc006a40, 1001e1d60, 1001e36c0, ffffffff2e0ff7e0) + 1d0
 ffffffb075b833d4 __1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_pnGSymbol_6pnGThread__v_ (ffffffff2e0ff968, 103642240, ffffffb076db99a0, 7fc006a40, 1001e1d60, 1001e36c0) + cc
 ffffffb075d008e4 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (103641000, 0, 89c00, ffffffff2e0ff978, ffffffb076d76568, 7fc006a40) + f4
 ffffffb07632e6c0 __1cKJavaThreadRthread_main_inner6M_v_ (103641000, ffffffff2e0ffb40, ffffffff2e0ffac8, 9d400, ffffffb076b36f16, ffffffb076e001d7) + 260
 ffffffb07632e3e0 __1cKJavaThreadDrun6M_v_ (103641000, 5a38, e7, ffffffb076b370c0, ffffffb076d76568, 103641210) + 4f8
 ffffffb0760a50a0 java_start (103641000, ffffffb076dff88d, 0, 103643250, c0000, ffffffb076d76568) + 370
 ffffffff7eee25b4 _lwp_start (0, 0, 0, 0, 0, 0)
Comments
Is there a reason not to close this as a dup of JDK-8049304?
21-01-2015

I agree this looks like 8049304. The VM is at a safepoint and the VMThread has already finished doing any internal VM shutdown. The crashing thread is in EnterI after being safepoint-safe and hits a deallocated resource. All the other threads are blocked but it does look like System.exit is being called while there is a lot of activity.
09-01-2015

ILW HL? = P2 I: High, Crash L: Low, Only been seen once W: Unknown (High), No known workaround at this point
08-01-2015

This failure makes me think of the following bug: JDK-8049304 race between VM_Exit and _sync_FutileWakeups->inc() In particular, this part of the failing thread: --- called from signal handler with signal 10 (SIGBUS) --- ffffffb07607b7c0 __1cNObjectMonitorGEnterI6MpnGThread__v_ (102caba00, 103641000, 200, bc90c, ffffffb076d76568, ffffffb0769fc53d) + 520 ffffffb07607ac7c __1cNObjectMonitorFenter6MpnGThread__v_ (102caba00, 103641000, 3, ffffffb076e001d7, ffffffb076d76568, ffffffb0769fb925) + 5b4 ffffffb0762cb9e0 __1cSObjectSynchronizerKslow_enter6FnGHandle_pnJBasicLock_pnGThread__v_ (102caba02, ffffffff2e0fcd50, 103641000, ffffffb076b136d8, 3, ffffffb076d76568) + 300 ffffffb0762cb404 __1cSObjectSynchronizerKfast_enter6FnGHandle_pnJBasicLock_bpnGThread__v_ (102caba02, ffffffff2e0fcd50, 7dc0c9e20, 103641000, ffffffb076e001d7, 5a800) + 194 ffffffb075653ecc __1cIRuntime1Mmonitorenter6FpnKJavaThread_pnHoopDesc_pnPBasicObjectLock__v_ (103641000, 7dc0c9e20, ffffffff2e0fcd50, 310e, ffffffb07657d5fd, ffffffb076d76568) + 414
08-01-2015

The .log file shows: [2015-01-07T12:41:27.73] >>> Testing done and this thread looks like the Java main() thread: ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7eee75d4 ___lwp_cond_wait (100111450, 100111438, ffffffff, ffffffff7eebe204, 0, ffffffffffffffff) + 8 ffffffb0760b415c __1cCosNPlatformEventEpark6M_v_ (100111400, 0, 100111438, ffffffb076e82838, ffffffb076a1a130, ffffffb076d76568) + 164 ffffffb07601ca2c __1cHMonitorFIWait6MpnGThread_l_i_ (10010d9a0, 10010f800, 0, 89c00, 100111400, ffffffb076d76568) + dc ffffffb07601e288 __1cHMonitorEwait6Mblb_b_ (10010d9a0, 10010f800, 0, 100111af0, ffffffb0769c73da, bdf08) + 5a0 ffffffb07641d2f8 __1cIVMThreadHexecute6FpnMVM_Operation__v_ (ffffffff7defece8, ffffffb076d7e6c0, 10010d9a0, 1b, 10010f800, 0) + 238 ffffffb075b7ca14 __1cHvm_exit6Fi_v_ (5f, 10010d460, ffffffb076e001d3, ffffffb076d76568, 10010f800, ffffffff7defece8) + cc ffffffb075cd19c8 JVM_Halt (5f, 10010f800, 4, 100110a90, ffffffb076d76568, 3) + 230 ffffffb074a17fec Java_java_lang_Shutdown_halt0 (10010fa40, ffffffff7defef88, 5f, ffffffb076dff881, 0, ffffffb076e001d7) + 4 ffffffff6ff637c4 * java/lang/Shutdown.halt(I)V+19152 ffffffff68008858 * java/lang/Shutdown.halt(I)V+7 ffffffff68008858 * java/lang/Runtime.halt(I)V+14 ffffffff68e69eb0 ???????? (7dc091538, ffffffff6506acf0, 1, 0, 70, 1e) + ffffffffee4484d8 ffffffff68b8a924 ???????? (7f166fd40, 4e20, 100111998, ffffffff7deffb20, 100110e10, ffffffff7defeda1) + ffffffffee168f4c ffffffff6800053c * StubRoutines (1) ffffffb075b84b40 __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (ffffffff7deffe10, ffffffb076e404a8, ffffffff65066678, 0, 10010f808, 1) + 950 ffffffb075c21adc __1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_ArgumentPusher_pnGThread__v_ (10010fa40, ffffffff7deffe10, 10010f800, e, ffffffb076893264, ffffffff7deffa80) + a64 ffffffb075c4c140 jni_CallStaticVoidMethod (10010fa40, 21f, 10050adb0, 10010f800, 1ae8, ffffffff7defff08) + 508 ffffffb076f08694 JavaMain (100111998, 100111980, 10050adb0, ffffffb076f147d8, ffffffb077016110, 100101800) + 584 ffffffff7eee25b4 _lwp_start (0, 0, 0, 0, 0, 0) and we have the VMThread here: ----------------- lwp# 46 / thread# 46 -------------------- ffffffff7eee7c6c _syscall6 (ffffffffffd19553, ffffffb076c0ea50, 2, 1, ffffffb076c0ea50, 2e6800) + 20 ffffffff7eed3b40 open (ffffffb076c0ea50, 0, 1, ffffffff7f0875c4, 2, ffffffff77c06240) + 74 ffffffb075905a40 dtrace_dof_fini (ffffffffffe98618, 167800, ffffffb076d76568, 81400, 1470b54, 81400) + 30 ffffffb076458e8c _fini (0, 0, 0, ffffffff7f7430e0, 3, ffffffff77c06240) + c ffffffff7f61c7d4 call_fini (ffffffff7f73e290, ffffffff4e201d98, 0, ffffffff4d500030, ffffffff7f73e538, ffffffff7f73ee58) + 104 ffffffff7f61c904 atexit_fini (ffffffff7f73e290, 41081, 1081, 1225c8, ffffffff7f73ee58, 40000) + 78 ffffffff7ee6b310 _exithandle (ffffffff514ff440, ffffffff7f084c80, 2880, 2800, 89000, 0) + 50 ffffffff7ee5ad54 exit (5f, 42b20, 42800, 1, 100101d50, 100101d50) + 4 ffffffb07641ff8c __1cMVM_OperationIevaluate6M_v_ (ffffffff7defece8, ffffffb076d76568, 9d6e0, ffffffb076bed508, 100422800, ffffffb076d76568) + ec ffffffb07641bd00 __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_ (ffffffb076e008c3, ffffffff7defece8, ffffffb076c4d293, ffffffb0754d2770, ffffffb076beb2cb, ffffffb076d76568) + 240 ffffffb07641c744 __1cIVMThreadEloop6M_v_ (8a000, ffffffb076e643f0, 0, ffffffb076e643e8, ffffffb076d76568, ede78) + 5dc ffffffb07641b7e4 __1cIVMThreadDrun6M_v_ (100422800, ffffffb076e77abc, 7f, 100417d10, 18c400, ffffffb076d76568) + 11c ffffffb0760a50a0 java_start (100422800, ffffffb076dff88d, 0, 100424930, c0000, ffffffb076d76568) + 370 ffffffff7eee25b4 _lwp_start (0, 0, 0, 0, 0, 0) However, if you look at many of the other thread in the pstack.core file, it sure looks like there is still a LOT going on for a VM that is shutting down.
08-01-2015