JDK-8217348 : assert(thread->is_Java_thread()) failed: just checking
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2019-01-17
  • Updated: 2021-10-13
  • Resolved: 2019-06-17
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 11 JDK 13 JDK 14 Other
11.0.12Fixed 13 b26Fixed 14Fixed openjdk8u302Fixed
Related Reports
Relates :  
JDK-8223736 - jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails due to wrong number of MonitorContendedEntered events
Relates :  
JDK-8224555 - vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed
Description
vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java failed:

Started recording 1. No limit specified, using maxsize=250MB as default.

Use jcmd 17684 JFR.dump name=1 filename=FILEPATH to copy recording data to file.
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\\runtime/thread.hpp:2046
[thread 26848 also had an error]
   JavaThread state: _thread_in_native_trans
[thread 37032 also had an error]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\runtime/thread.hpp:2046), pid=17684, tid=40836
#  assert(thread->is_Java_thread()) failed: just checking
#
# JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build 12-internal+0-jdk12-jdk.1234)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 12-internal+0-jdk12-jdk.1234, mixed mode, sharing, tiered, compressed oops, g1 gc, windows-amd64)
# Core dump will be written. Default location: T:\\testOutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti_quick\\scratch\\1\\hs_err_pid17684.mdmp
#
# An error report file with more information is saved as:
# T:\\testOutput\\test-support\\jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti_quick\\scratch\\1\\hs_err_pid17684.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Comments
Fix Request [8u] Backport this change to fix an obvious typo. Original patch does not apply cleanly to 8u due to changes in surrounding context. 8u RFR thread (acked by Zhengyu Gu): https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013717.html
26-04-2021
Fix request (11u) Backport to fix this obvious typo. Patch applies cleanly to 11u. Tier1-3 tested with fastdebug x86_64 linux build.
30-03-2021
URL: http://hg.openjdk.java.net/jdk/jdk13/rev/09ee0bd26bda User: dtitov Date: 2019-06-17 21:33:03 +0000
17-06-2019
Thank you, David, for finding this!
14-06-2019
I took another look at the code but again we seem to hit the impossible: we must be at a safepoint (which the hs_err log confirms) but the code that fails is only executed if we are NOT at a safepoint! Either SafepointSynchronize::is_at_safepoint() is giving the wrong answer, or else the C compiler has generated incorrect code. Latest hs_err shows we are at the following code: for (int i = 0; i < nWant; i++) { JavaThread *pending_thread = wantList->at(i); // If the monitor has no owner, then a non-suspended contending // thread could potentially change the state of the monitor by // entering it. The JVM/TI spec doesn't allow this. if (owning_thread == NULL && !at_safepoint & !pending_thread->is_thread_fully_suspended(true, &debug_bits)) { Oh! Just spotted the problem - use of '&' instead of '&&' - the compiler can now reorder the checks! Correction: this isn't Java so & is bitwise-AND so we will always evaluate pending_thread->is_thread_fully_suspended if we hit this code. So I am surprised we don't see this crash much more often.
14-06-2019
We seem to be executing either if (!at_safepoint && !owning_thread->is_thread_fully_suspended(true, &debug_bits)) { or if (owning_thread == NULL && !at_safepoint & !pending_thread->is_thread_fully_suspended(true, &debug_bits)) { implying we are not at a safepoint. But this is within VM_GetObjectMonitorUsage::doit and we are at a safepoint!
03-02-2019
This code: bool JavaThread::is_thread_fully_suspended(bool wait_for_suspend, uint32_t *bits) { if (this != JavaThread::current()) { only ever expects to be called by a JavaThread - hence the assertion failure in: // Inline implementation of JavaThread::current inline JavaThread* JavaThread::current() { Thread* thread = Thread::current(); assert(thread->is_Java_thread(), "just checking"); return (JavaThread*)thread; } Has something changed in the way VM_GetObjectMonitorUsage::doit and related code works ??
29-01-2019
More from hs_err: Current thread (0x0000004eff915000): VMThread "VM Thread" [stack: 0x0000004effaf0000,0x0000004effbf0000] [id=40836] _threads_hazard_ptr=0x0000004e9c827b60, _nested_threads_hazard_ptr_cnt=0 Stack: [0x0000004effaf0000,0x0000004effbf0000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xb61401] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:369) V [jvm.dll+0xd80f70] VMError::report+0xe80 (vmerror.cpp:698) V [jvm.dll+0xd827c4] VMError::report_and_die+0x854 (vmerror.cpp:1471) V [jvm.dll+0xd82e84] VMError::report_and_die+0x64 (vmerror.cpp:1295) V [jvm.dll+0x581b8e] report_vm_error+0x7e (debug.cpp:232) V [jvm.dll+0xd20e51] JavaThread::is_thread_fully_suspended+0x61 (thread.cpp:807) V [jvm.dll+0x957bb7] JvmtiEnvBase::get_object_monitor_usage+0x507 (jvmtienvbase.cpp:1084) V [jvm.dll+0x953ec4] VM_GetObjectMonitorUsage::doit+0x24 (jvmtienvbase.hpp:415) V [jvm.dll+0xd8413e] VM_Operation::evaluate+0xbe (vmoperations.cpp:68) V [jvm.dll+0xd89458] VMThread::evaluate_operation+0xb8 (vmthread.cpp:416) V [jvm.dll+0xd89d04] VMThread::loop+0x404 (vmthread.cpp:547) V [jvm.dll+0xd8a842] VMThread::run+0xf2 (vmthread.cpp:315) V [jvm.dll+0xd1a5eb] Thread::call_run+0x21b (thread.cpp:394) V [jvm.dll+0xb5fcb3] thread_native_entry+0x123 (os_windows.cpp:459) C [ucrtbase.DLL+0x1d885] C [KERNEL32.DLL+0x13d2] C [ntdll.dll+0x154f4] VM_Operation (0x0000004e9eeeea10): GetObjectMonitorUsage, mode: safepoint, requested by thread 0x0000004e9e7f9000
17-01-2019