JDK-8062688 : nsk/jdi/MonitorContendedEnterRequest/addClassExclusionFilter crashes in ObjectMonitor::EnterI()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_11
  • CPU: sparc
  • Submitted: 2014-11-01
  • Updated: 2015-09-23
  • Resolved: 2015-09-23
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 :  
JDK-8049304 - race between VM_Exit and _sync_FutileWakeups->inc()
Description
ObjectMonitor::EnterI() is seeing a poison value 0xbabababababababa.
Comments
I agree with Dan, this bug looks like a dup of the JDK-8049304 that has been fixed on 9/3/2015. Jdash does not show any nightly failures with this bug pattern in September. So, I'm closing it as a dup.
23-09-2015
Based on this snippet in the .out file: debugee.stderr> Debuggee: received the command: quit debugee.stderr> Debuggee: exiting debugee.stdout> # debugee.stdout> # A fatal error has been detected by the Java Runtime Environment: debugee.stdout> # debugee.stdout> # SIGBUS (0xa) at pc=0xffffffe551c75550, pid=23539, tid=9 debugee.stdout> # debugee.stdout> # JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-201411010008.vkozlov.8054492-b00) debugee.stdout> # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-fastdebug-201411010008.vkozlov.8054492-b00 compiled mode solaris-sparc compressed oops) debugee.stdout> # Problematic frame: debugee.stdout> # V [libjvm.so+0x1275550] void ObjectMonitor::EnterI(Thread*)+0x520 The debuggee is finished and is exiting. Here is the crashing thread from the pstack.core file: ----------------- lwp# 9 / thread# 9 -------------------- 0000000000000000 ???????? (ffffffff66afddd8, ffffffff66afdc40, 1f8000, ffffffffffe07cda, 1, ffffffe552764cd5) + ddfde628 ffffffe551fe91f8 __1cHVMErrorOreport_and_die6M_v_ (ffffffff66afddd8, ffffffe551cb53e0, ffffffff66afdc40, ffffffe552a387e8, 1, 7d0) + 6f8 ffffffe551cb1c94 JVM_handle_solaris_signal (a, ffffffff66afe560, c0800, ffffffff66afddd8, ffffffff66afe280, 10047e800) + c6c ffffffe551ca9d24 signalHandler (a, ffffffff66afe560, ffffffff66afe280, 0, 0, 0) + 1c ffffffff7eee26ac __sighndlr (a, ffffffff66afe560, ffffffff66afe280, ffffffe551ca9d08, 0, ffffffff7f07e000) + c ffffffff7eed5ce0 call_user_handler (ffffffff7dd03a40, ffffffff66afe560, ffbffeff, 0, 0, a) + 364 ffffffff7eed5f10 sigacthandler (a, ffffffff66afe560, ffffffff66afe280, 1a8148, ffffffff7f07e000, a) + 5c --- called from signal handler with signal 10 (SIGBUS) --- ffffffe551c75550 __1cNObjectMonitorGEnterI6MpnGThread__v_ (100db7880, 10047e800, 8, 0, ffffffe55295d550, ffffffe5525e6e3a) + 520 ffffffe551c74a0c __1cNObjectMonitorFenter6MpnGThread__v_ (100db7880, 10047e800, 3, ffffffe5529e73b7, ffffffe55295d550, ffffffe5525e623a) + 5b4 ffffffe551ec73d8 __1cSObjectSynchronizerKslow_enter6FnGHandle_pnJBasicLock_pnGThread__v_ (ffffffff666ff000, ffffffff66afef00, 10047e800, ffffffe5526fdfe7, 3, ffffffe55295d550) + 300 ffffffe551ec6dfc __1cSObjectSynchronizerKfast_enter6FnGHandle_pnJBasicLock_bpnGThread__v_ (ffffffff666ff000, ffffffff66afef00, 7ab705338, 10047e800, ffffffe5529e73b7, 5a800) + 194 ffffffe551252734 __1cIRuntime1Mmonitorenter6FpnKJavaThread_pnHoopDesc_pnPBasicObjectLock__v_ (10047e800, 7ab705338, ffffffff66afef00, 305, ffffffe552171bca, ffffffe55295d550) + 414 ffffffff681c306c * monitorenter_nofpu Runtime1 stub ffffffff6881223c ???????? (7ab705338, 7ab752910, 0, 8f4000, 70, 1e) + 467f0864 ffffffff6fbb6614 ???????? (7ab752910, 4e20, 10047f8f0, ffffffff66aff5f0, ffffffff66aff908, ffffffff66afe7b1) + 4db94c3c ffffffff6800053c * StubRoutines (1) ffffffe55178024c __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (ffffffff66aff7b8, ca400, ffffffff66aff5e0, 10047e808, ffffffff794350d8, 1) + 94c ffffffe55177e978 __1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_pnGSymbol_5pnRJavaCallArguments_pnGThread__v_ (ffffffff66aff7b8, 89c00, 7c0006a40, 1001d8540, 1001d9e90, ffffffff66aff5e0) + 1d0 ffffffe55177ea9c __1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_pnGSymbol_6pnGThread__v_ (ffffffff66aff7b8, 10047f8f0, ffffffe5529a0968, 7c0006a40, 1001d8540, 1001d9e90) + cc ffffffe551f2a61c __1cKJavaThreadEexit6Mbn0AIExitType__v_ (10047e800, 2, 0, 1, ffffffff66aff7d8, ffffffe55295d550) + 65c ffffffe551f29d70 __1cKJavaThreadRthread_main_inner6M_v_ (10047e800, 5, 7ab752910, ffffffff66aff9f8, ffffffe552721ee2, ffffffe5529e73b7) + 3a8 ffffffe551f29948 __1cKJavaThreadDrun6M_v_ (10047e800, 59e0, 5, ffffffe552721610, ffffffe55295d550, 10047ea10) + 4f8 ffffffe551c9ed3c java_start (10047e800, 896e2, ffffffe5529e6c32, 0, ffffffe552a0ae70, ffffffe55295d550) + 414 ffffffff7eee25b4 _lwp_start (0, 0, 0, 0, 0, 0) Here's the thread that is shutting down the VM: ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7eee75d4 ___lwp_cond_wait (100112c50, 100112c38, ffffffff, ffffffff7eebe204, 0, ffffffffffffffff) + 8 ffffffe551cadc3c __1cCosNPlatformEventEpark6M_v_ (100112c00, 0, 100112c38, ffffffe552a691b8, ffffffe55260472e, ffffffe55295d550) + 164 ffffffe551c16acc __1cHMonitorFIWait6MpnGThread_l_i_ (10010f170, 100111000, 0, 89e67, 100112c00, ffffffe55295d550) + dc ffffffe551c182c0 __1cHMonitorEwait6Mblb_b_ (10010f170, 100111000, 0, ffffffe552a1b620, c77c0, 4) + 558 ffffffe552018838 __1cIVMThreadHexecute6FpnMVM_Operation__v_ (ffffffff7defeaf8, ffffffe5529656a0, 10010f170, 73f, 100111000, 0) + 238 ffffffe551778124 __1cHvm_exit6Fi_v_ (5f, 10010ec30, ffffffe5529e73b3, ffffffe55295d550, 100111000, ffffffff7defeaf8) + cc ffffffe5518cb1b0 JVM_Halt (5f, 100111000, 4, 100112260, ffffffe55295d550, 3) + 230 ffffffe550617d4c Java_java_lang_Shutdown_halt0 (100111240, ffffffff7defed98, 5f, 3, 1003f6b30, ffffffe55295d550) + 4 ffffffff6fbbcf44 ???????? (5f, 8, ffffffff7977a510, ffffffe5529e6a29, 0, ffffffe5529e73b7) + 4db9b56c ffffffff686226c8 * java/lang/Shutdown.exit(I)V+4806 ffffffff68008858 * java/lang/Shutdown.exit(I)V+99 ffffffff685913f8 * nsk/share/jpda/AbstractDebuggeeTest.doTest()V+-20432 ffffffff68008858 * nsk/share/jpda/AbstractDebuggeeTest.doTest()V+210 ffffffff68008858 * nsk/share/jpda/AbstractDebuggeeTest.doTest([Ljava/lang/String;)V+6 ffffffff68008858 * nsk/share/jdi/MonitorEventsDebuggee.main([Ljava/lang/String;)V+10 ffffffff6800053c * StubRoutines (1) ffffffe55178024c __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ (ffffffff7deffe10, ca400, ffffffff7deffb10, 100111008, ffffffff79800768, 1) + 94c ffffffe55181b274 __1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_ArgumentPusher_pnGThread__v_ (100111240, ffffffff7deffe10, 100111000, e, ffffffe55247fbe5, ffffffff7deffa80) + a64 ffffffe5518459a0 jni_CallStaticVoidMethod (100111240, a0, 1005615a8, 100111000, 1ad8, ffffffff7defff08) + 508 ffffffe54f90897c JavaMain (100113168, 100113150, 1005615a8, ffffffe54f915b90, ffffffe54fa17648, 1001018c0) + 584 ffffffff7eee25b4 _lwp_start (0, 0, 0, 0, 0, 0) Based on the above bits of data, this failure looks like a duplicate of this bug: JDK-8049304 race between VM_Exit and _sync_FutileWakeups->inc() Serguei, if you agree, we can close this bug as a duplicate of JDK-8049304.
27-08-2015
Since it's a JDI test let serviceability take a look.
06-11-2014
[~twisti], not sure, it didn't seem obvious to me what category it should be in. Please feel free to change it.
05-11-2014
[~iveresov], why did you file this one in hotspot/compiler?
05-11-2014
ILW=Crash, once so far, none=HLH=P2 + nightly = P1
05-11-2014