JDK-8048152 : Unexpected Signal 10 occurred under user-defined signal handler
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2014-06-25
  • Updated: 2015-01-21
  • Resolved: 2015-01-21
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
During nightly testing for 6/24/2014 the test

nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock//JavaDeadlock00

failed after test completion with

[2014-06-25T07:12:40.01] TEST PASSED
[2014-06-25T07:12:59.57] Java HotSpot(TM) 64-Bit Server VM warning: Java HotSpot(TM) 64-Bit Server VM warning: Unexpected Signal 10 occurred under user-defined signal handler 0xffffffff7d6d3378# Test level exit status: 11
Comments
Although reported first this is the same issue as JDK-8049304 which has been extensively investigated, so closing this one as a duplicate.
21-01-2015
ILW ML? = P4 I: Medium, Crashes, but it's during shutdown so impact set to Medium. L: Low, Seems like a very rare case W: Unknown (High),
30-06-2014
A couple of observations: - The test does not install any signal handlers. I don't know why hotspot thinks there is a user defined signal handler. Is there a race during shutdown were the hotspot signal handler is being removed at the same time? Do we remove the signal handler? - This perf counter is never deallocated. In general we do not deallocate the memory mapped perf memory, see delete_shared_memory() in perfMemory_solaris.cpp. There are cases where perf counters are malloced() in which case they can be deallocated, but there is no code that calls "delete" on _sync_FutileWakeups as far as I can see. Why the memory is full of "ababababa" I can't explain.
26-06-2014
Yes, this looks like a problem with shutdown. The PerfCounter may already have been deallocated.
26-06-2014
If the test already passed is this occurring during VM termination? The ABABA pattern comes from GuardedMemory.
26-06-2014
_sync_FutileWakeups is bad dbx: print -r *ObjectMonitor::_sync_FutileWakeups *ObjectMonitor::_sync_FutileWakeups = { PerfLongCounter::PerfLongVariant::PerfLong::PerfData::_name = 0xbabababababababa "<bad address 0xbabababa>" PerfLongCounter::PerfLongVariant::PerfLong::PerfData::_v = -1162167622 PerfLongCounter::PerfLongVariant::PerfLong::PerfData::_u = -1162167622 PerfLongCounter::PerfLongVariant::PerfLong::PerfData::_on_c_heap = true PerfLongCounter::PerfLongVariant::PerfLong::PerfData::_flags = -1162167622 PerfLongCounter::PerfLongVariant::PerfLong::PerfData::_pdep = 0xbabababababababa PerfLongCounter::PerfLongVariant::PerfLong::PerfData::_valuep = 0xbabababababababa PerfLongCounter::PerfLongVariant::_sampled = 0xbabababababababa PerfLongCounter::PerfLongVariant::_sample_helper = 0xbabababababababa } dbx: print UsePerfData UsePerfData = true dbx: whatis ObjectMonitor::_sync_FutileWakeups __hidden static PerfCounter *_sync_FutileWakeups; in this stack trace current thread: t@14 [1] 0x0(0xffffffff7e93dd18, 0xffffffff156a5260, 0x2, 0x0, 0x0, 0x0), at 0x0 [2] outputStream::print_raw(this = 0xffffffff7e93dd18, str = 0xffffffff156a5260 "#\n", len = 0x2), line 89 in "ostream.hpp" [3] staticBufferStream::write(this = 0xffffffff156a6520, c = 0xffffffff156a5260 "#\n", len = 0x2U), line 1175 in "ostream.cpp" [4] outputStream::print_cr(this = 0xffffffff156a6520, format = 0xffffffff7e53416a "#", ...), line 140 in "ostream.cpp" [5] VMError::report(this = 0xffffffff156a67f8, st = 0xffffffff156a6520), line 401 in "vmError.cpp" [6] VMError::report_and_die(this = 0xffffffff156a67f8), line 972 in "vmError.cpp" [7] JVM_handle_solaris_signal(sig = 0xa, info = 0xffffffff156a7020, ucVoid = 0xffffffff156a6d40, abort_if_unrecognized = 0x1), line 549 in "os_solaris_sparc.cpp" [8] signalHandler(sig = 0xa, info = 0xffffffff156a7020, ucVoid = 0xffffffff156a6d40), line 3921 in "os_solaris.cpp" [9] __sighndlr(0xa, 0xffffffff156a7020, 0xffffffff156a6d40, 0xffffffff7dab9350, 0x0, 0x9), at 0xffffffff7eed65b4 ---- called from signal handler with signal 10 (SIGBUS) ------ [10] PerfLongVariant::inc(this = 0x100112c70), line 425 in "perfData.hpp" =>[11] ObjectMonitor::EnterI(this = 0x10068fb78, __the_thread__ = 0x1007b8000), line 609 in "objectMonitor.cpp" [12] ObjectMonitor::enter(this = 0x10068fb78, __the_thread__ = 0x1007b8000), line 371 in "objectMonitor.cpp" [13] ObjectSynchronizer::slow_enter(obj = CLASS, lock = 0xffffffff156a7930, __the_thread__ = 0x1007b8000), line 233 in "synchronizer.cpp" [14] ObjectSynchronizer::fast_enter(obj = CLASS, lock = 0xffffffff156a7930, attempt_rebias = true, __the_thread__ = 0x1007b8000), line 155 in "synchronizer.cpp" [15] InterpreterRuntime::monitorenter(thread = 0x1007b8000, elem = 0xffffffff156a7930), line 602 in "interpreterRuntime.cpp" [16] 0xffffffff6b04cee4(0xffffffff194683b8, 0xb6, 0x0, 0xffffffff6b04cbc0, 0x10053fc98, 0xffffffff156a7181), at 0xffffffff6b04cee4 [17] 0xffffffff6b007eb8(0xffffffff194683b8, 0xb6, 0x0, 0xffffffff6b048e60, 0xffffffff65a7e5f8, 0xffffffff156a72a1), at 0xffffffff6b007eb8 [18] 0xffffffff6b007eb8(0xffffffff19466850, 0xb6, 0x0, 0xffffffff6b048e60, 0xffffffff15a04498, 0xffffffff156a73c1), at 0xffffffff6b007eb8 [19] 0xffffffff6b007eb8(0xffffffff65a7e5c8, 0x1007b8000, 0x0, 0xffffffff6b048e60, 0xffffffff156a8429, 0xffffffff156a74c1), at 0xffffffff6b007eb8 [20] 0xffffffff6b0004b8(0xffffffff156a7eb0, 0xffffffff156a8638, 0xa, 0xffffffff18c73b00, 0xffffffff6b01a0e0, 0xffffffff156a83f8), at 0xffffffff6b0004b8 [21] JavaCalls::call_helper(result = 0xffffffff156a8630, m = 0xffffffff156a8350, args = 0xffffffff156a83d8, __the_thread__ = 0x1007b8000), line 393 in "javaCalls.cpp" [22] os::os_exception_wrapper(f = 0xffffffff7d5f1f18 = &JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*), value = 0xffffffff156a8630, method = 0xffffffff156a8350, args = 0xffffffff156a83d8, thread = 0x1007b8000), line 3884 in "os_solaris.cpp" [23] JavaCalls::call(result = 0xffffffff156a8630, method = CLASS, args = 0xffffffff156a83d8, __the_thread__ = 0x1007b8000), line 307 in "javaCalls.cpp" [24] jni_invoke_nonstatic(env = 0x1007b8228, result = 0xffffffff156a8630, receiver = 0xffffffff156a8a78, call_type = JNI_VIRTUAL, method_id = 0x10053fc98, args = 0xffffffff156a85f0, __the_thread__ = 0x1007b8000), line 1193 in "jni.cpp" [25] jni_CallVoidMethod(env = 0x1007b8228, obj = 0xffffffff156a8a78, methodID = 0x10053fc98, ...), line 1579 in "jni.cpp" [26] Java_nsk_share_monitoring_thread_RecursiveMonitoringThread_nativeRecursiveMethod(0x1007b8228, 0xffffffff15a041f8, 0x99, 0xffffffff15a04278, 0xffffffff15a04498, 0x100780658), at 0xffffffff15a03a48
26-06-2014
RULE nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock002 ExitCode 11
25-06-2014
I assigned to serviceability because the signal 10 may have occurred while the "user defined signal handler" was running. I'm assuming it was a signal handler supplied by the test.
25-06-2014