JDK-8057907 : Test nsk/jdi/ClassPrepareRequest/addSourceNameFilter/addSourceNameFilter002 fails with SIGBUS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris
  • CPU: sparc_64
  • Submitted: 2014-09-09
  • Updated: 2014-09-29
  • Resolved: 2014-09-29
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 :  
Relates :  
Description
From log file:
...
[2014-09-06T08:37:16.02] debugee.stdout> # A fatal error has been detected by the Java Runtime Environment:
[2014-09-06T08:37:16.02] debugee.stdout> #
[2014-09-06T08:37:16.02] debugee.stdout> #  SIGBUS (0xa) at pc=0xffffffff7d668ec8, pid=13459, tid=50
[2014-09-06T08:37:16.02] debugee.stdout> #
[2014-09-06T08:37:16.02] debugee.stdout> # JRE version: Java(TM) SE Runtime Environment (9.0-b29) (build 1.9.0-ea-fastdebug-b29)
[2014-09-06T08:37:16.02] debugee.stdout> # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-fastdebug-internal-201409052141.iggy.8056154 compiled mode solaris-sparc compressed oops)
[2014-09-06T08:37:16.02] debugee.stdout> # Problematic frame:
[2014-09-06T08:39:17.37] debugee.stdout> # V  [libjvm.so+0x1268ec8]
[2014-09-06T08:39:18.03] # ERROR: TEST FAILED: debuggee's process finished with status: 11
...
Comments
I think this is a duplicate of the following bug: JDK-8049304 race between VM_Exit and _sync_FutileWakeups->inc() I'll let the triage process decide...
26-09-2014

It is runtime issue during VM shutdown.
26-09-2014

I thought of two possible solutions: 1) Avoid freeing memory in perfMemory_exit(). As perfMemory_exit() is called only when the VM is to be shut down, memory will be reclaimed anyway by the OS (but that might not be true on all OSs we support). Moreover, freeing is avoided anyway if the StatsSampler is active. 2) Set thread state to "_thread_blocked" later, that is, in ObjectMonitor::EnterI(), just before calling Self->_ParkEvent->park().
26-09-2014

I analyzed the core file. The SIGBUS signal is thrown in thread 0x32 at frame 10. Current SP = 0xffffffff2b5fc2f0 FP: 0xffffffff2b5fcb80 0 PC=0x0 1 PC=0xffffffff7cf29aec libjvm.so+0xb29aec frame::print_C_frame()+292 2 PC=0xffffffff7d9dacbc libjvm.so+0x15dacbc VMError::report()+1540 3 PC=0xffffffff7d9dc424 libjvm.so+0x15dc424 VMError::report_and_die()+900 4 PC=0xffffffff7d9dc424 libjvm.so+0x15dc424 VMError::report_and_die()+900 5 PC=0xffffffff7d6a58bc libjvm.so+0x12a58bc JVM_handle_solaris_signal+3348 6 PC=0xffffffff7d69cf54 libjvm.so+0x129cf54 signalHandler+36 7 PC=0xffffffff7ead88ac libc.so.1+0xd88ac 8 PC=0xffffffff7eacc420 libc.so.1+0xcc420 9 PC=0xffffffff7eacc62c libc.so.1+0xcc62c >10 PC=0xffffffff7d668e20 libjvm.so+0x1268e20 ObjectMonitor::EnterI()+1144 11 PC=0xffffffff7d668390 libjvm.so+0x1268390 ObjectMonitor::enter()+1472 12 PC=0xffffffff7d8baeb0 libjvm.so+0x14baeb0 ObjectSynchronizer::slow_enter()+776 13 PC=0xffffffff7d8ba8d4 libjvm.so+0x14ba8d4 ObjectSynchronizer::fast_enter()+412 Warning: frame pointer contains same frame pointer? Thread 0x32 at 0xffffffff2b5fee20 14 PC=0xffffffff7d7f2c64 libjvm.so+0x13f2c64 SharedRuntime::complete_monitor_locking_C()+1092 StackFrame.init: java.lang.NullPointerException ret addr=0xffffffff6a938828 core The instruction that causes the SIGBUS is void ObjectMonitor::EnterI(Thread*)+0x520: de 5c 20 00 ldx [%l0], %o7 which corresponds to loading the address of ObjectMonitor::_sync_FutileWakeups::_valuep in perfData.hpp 425: inline void inc() { (*(jlong*)_valuep)++; } The method inc() is called from objectMonitor.cpp 595: if (ObjectMonitor::_sync_FutileWakeups != NULL) { 596: ObjectMonitor::_sync_FutileWakeups->inc(); 597: } The SIGBUS signal is thrown because the address in ObjectMonitor::_sync_FutileWakeups::_valuep is invalid (0xbabababababababa). The following scenario leads to the invalid address in _valuep: Thread_1: User code calls System.exit(). VM_Thread: The VM_Exit operation is started. Thread_2: Calls ObjectMonitor::enter(), sets state of Thread_2 to "_thread_blocked". VM_Thread: Sets SafepointSynchronize::_state to "synchronized". Calls exit_globals(), then perfMemory_exit(), then PerfDataManager::destroy(), which frees the memory pointed to by ObjectMonitor::_sync_FutileWakeups::_valuep . Thread_2: Calls ObjectMonitor::EnterI() that results in SIGBUS.
26-09-2014

ILW=crash;one time;none=HLH=>P2
09-09-2014