JDK-8231666 : ThreadIdTable::grow() invokes invalid thread transition
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-10-01
  • Updated: 2020-01-31
  • Resolved: 2019-10-08
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 14
14 b18Fixed
Related Reports
Relates :  
JDK-8185005 - Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
Relates :  
JDK-8184732 - Deadlock detection improvements for 'special' locks
Description
Stack: [0xfffffffef0c00000,0xfffffffef0d00000],  sp=0xfffffffef0cfdbf0,  free space=1014k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x20a3014]  void VMError::report_and_die(int,const char*,const char*,void*,Thread*,unsigned char*,void*,void*,const char*,int,unsigned long)+0xb14
V  [libjvm.so+0x20a2498]  void VMError::report_and_die(Thread*,void*,const char*,int,const char*,const char*,void*)+0x38
V  [libjvm.so+0x13f1c58]  void report_fatal(const char*,int,const char*,...)+0x88
V  [libjvm.so+0x1fc5ed8]  void Thread::check_possible_safepoint()+0x78
V  [libjvm.so+0xfc4ee8]  void ThreadStateTransition::transition(JavaThread*,JavaThreadState,JavaThreadState)+0xc8
V  [libjvm.so+0x1fd9c3c]  void ThreadIdTable::grow(JavaThread*)+0x21c
V  [libjvm.so+0x1fda1e0]  JavaThread*ThreadIdTable::add_thread(long,JavaThread*)+0x120
V  [libjvm.so+0x1fd42fc]  void Threads::add(JavaThread*,bool)+0x18c
V  [libjvm.so+0x1fcfae8]  void JavaThread::prepare(_jobject*,ThreadPriority)+0x598
V  [libjvm.so+0x18e3d80]  JVM_StartThread+0x410
Comments
Kitchensink and regression tests passed
31-01-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/94dd00d2da29 User: dtitov Date: 2019-10-08 16:40:52 +0000
08-10-2019
JVM_StartThread owns the Threads_lock which means safepoints are impossible in that case. It also makes no sense to poll for safepoints in that case (and we should never be blocking while holding the Threads_lock). Simple fix is to skip the ThreadBlockInVM if the current thread owns the Threads_lock. It is less clear to me whether no_safepoint_verifier should restore the exemption of the Threads_lock.
02-10-2019
Seems to be caused by JDK-8184732 changes that no longer excludes Threads_lock from Mutex::no_safepoint_verifier() check. void Mutex::no_safepoint_verifier(Thread* thread, bool enable) { - // Threads_lock is special, since the safepoint synchronization will not start before this is - // acquired. Hence, a JavaThread cannot be holding it at a safepoint. So is VMOperationRequest_lock, - // since it is used to transfer control between JavaThreads and the VMThread - // Do not *exclude* any locks unless you are absolutely sure it is correct. Ask someone else first! - if ((_allow_vm_block && - this != Threads_lock && - this != Compile_lock && // Temporary: should not be necessary when we get separate compilation - this != tty_lock && // The tty_lock is released for the safepoint. - this != VMOperationRequest_lock && - this != VMOperationQueue_lock) || - rank() == Mutex::special) { + // The tty_lock is special because it is released for the safepoint by + // the safepoint mechanism. + if (this == tty_lock) { + return; + } + + if (_allow_vm_block) { if (enable) { thread->_no_safepoint_count++; } else {
02-10-2019