Open pgfisico opened 6 years ago
Is there any progress on this? I have this error on jdk 1.8.0_181-b13.
The segfault here is caused by a bug in HotSpot. It is fixed in JDK 11.
The reason TinyB hit the bug is that it would attach the thread without checking if it was already attached. As a result, for calls that were executing on a thread that started within Java, TinyB would attempt to detach the thread even though it was not a native thread.
For me, this was happening when using notifications. When the C++ code gets a global reference to the callback in Java code, it is re-attaching the thread that originated in Java. This is allowed by JNI and is a no-op. The problem is that it could not detach the thread correctly because the JVM had already cleaned up the thread on shutdown, leading to the null pointer from Thread::current()
.
https://bugs.openjdk.java.net/browse/JDK-8199012 https://bugs.java.com/view_bug.do?bug_id=8199012
A segmentation fault occurs when the JNIEnvContainer destructor detaches the thread and the JVM has already exited.
The cause is
Monitor::lock_without_safepoint_check()
receives a null pointer fromThread::current()
.Monitor::ILock()
receives the null pointer as the argument and the segmentation fault occurs whenMonitor::ILock()
dereferences the pointer to access_MutexEvent
._MutexEvent
is at an offset of 0xe4 withinThread
, which is confirmed by the offending si_addr of 0x000000e4.Issue also occurs when using Oracle JDK 8u152 Linux ARM 32 Hard Float ABI.
Issue appears similar to #66 and #59.
See also https://bugs.openjdk.java.net/browse/JDK-8033696
TinyB Version
0.5.0-28-gac6d308
hs_err_pid2261.log
GDB Session