Bug ID: JDK-8210131 vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code

Type: Bug
Component: hotspot
Sub-Component: jvmti
Affected Version: 11,12

Priority: P4
Status: Resolved
Resolution: Fixed
OS: linux,solaris
CPU: x86_64,sparc_64

Submitted: 2018-08-29
Updated: 2020-10-07
Resolved: 2018-09-07

JDK 11	JDK 12
11.0.10-oracleFixed	12 b11Fixed

3 failures on two different platforms, all with the same general error message:

The following fake exception stacktrace is for failuire analysis. 
nsk.share.Fake_Exception_for_RULE_Creation: (ap10t001.c:94) NSK_CPP_STUB2(GetCurrentThreadCpuTimerInfo, jvmti_env, &timer_info1 )
	at nsk_lvcomplain(nsk_tools.c:174)
# ERROR: ap10t001.c, 94: NSK_CPP_STUB2(GetCurrentThreadCpuTimerInfo, jvmti_env, &timer_info1 )
#   jvmti error: code=115, name=JVMTI_ERROR_UNATTACHED_THREAD
# ERROR: ap10t001.c, 97: ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code

# ERROR: ap10t001.c, 118: NSK_CPP_STUB2(GetCurrentThreadCpuTime, jvmti_env, &nanos )
#   jvmti error: code=115, name=JVMTI_ERROR_UNATTACHED_THREAD
# ERROR: ap10t001.c, 121: ObjectFree: GetCurrentThreadCpuTime returned unexpected error code
...

11u reapproval done.
27-08-2020
A bit of process nuisance: the patch does not actually apply cleanly because of the problem list addition. I think it is better to avoid that hunk altogether: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-August/003662.html. (Christoph, I removed jdk11u-fix-yes for your reapproval.)
27-08-2020
Fix Request (11u) This fixes a corner case in GC/JVMTI interaction. Patch applies cleanly to 11u, affected test fails with Shenandoah without the patch, passes with it. Additionally, tier{1,2} both with and without Shenandoah pass.
21-08-2020
Yes, fails reliably on 11u with Shenandoah and passes with the fix. Reproducer: $ CONF=linux-x86_64-normal-server-fastdebug make images run-test TEST=vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java TEST_VM_OPTS="-XX:+UseShenandoahGC" Seems to me it is exactly the scenario discussed here and in JDK-8203948: GC worker thread enters the JvmtiExport::weak_oops_do, gets to ObjectFree event, fails the check. Since the worker in question is NJT NamedThread, this fix resolves the failure.
21-08-2020
I observed the bug on recent 11u. Added affects-version accordingly.
20-08-2020
I finally figured out why these failures didn't show up when I was testing of JDK-8072498. Most of my testing of that patch included an optimization that kept the processing single-threaded on the VMThread when the amount of work is small, rather than handing the work off to a single WorkGang thread. During review, Thomas asked me to remove that, as it ought to be part of the WorkGroup infrastructure. I didn't run higher tier (>= 4) testing after making that change.
05-09-2018
[~dcubed] I was wondering the same thing. While this was uncovered by GC changes, the root cause is clearly in JVMTI. Moving it back. Need a 2nd review to push.
05-09-2018
Not sure why this bug was moved from hotspot/jvmti -> hotspot/gc. Yes, Kim B. is working on the issue, but this issue is squarely in hotspot/jvmti territory...
04-09-2018
[Initial comment deleted - seems I can't make up my mind as to whether we should explicitly enumerate the threads allowed to execute callbacks or not.]
03-09-2018
Moving this to hotspot/jvmti because it's not a compiler issue.
30-08-2018
Only the following functions can be called from an ObjectFree callback: Raw Monitor <list of functions> Memory Management Allocate Deallocate Environment Local Storage SetEnvironmentLocalStorage GetEnvironmentLocalStorage GetCurrentThreadCpuTimerInfo GetCurrentThreadCpuTime GetTimerInfo GetTime The Time and Timer functions are not mentioned in the ObjectFree callback documentation, but the documentation for those functions say they can be called from ObjectFree. With the exception of GetCurrentThreadCpuTimerInfo and GetCurrentThreadCpuTime, all of the functions that are callable from an ObjectFree callback use this little "transition" dance which used to permit the VMThread and Concurrent GC threads, and JDK-8203948 generalized that to any Named thread. GetCurrentThreadCpuTimerInfo and GetCurrentThreadCpuTime require a Java thread or the VM thread. JDK-8072498 introduced ObjectFree callbacks from GC worker threads, but makes no mention of the time functions. (A comment in JDK-4990379 suggests the GetCurrentThreadCpu* functions should be removed from the list of functions that may be called from the heap iteration callbacks. I wonder what the fix for this bug might have been.) These two functions are implemented using os::current_thread_cpu_time_info and os::current_thread_cpu_time, respectively. There's no reason for any calling thread restriction based on that. Changing is_VM_thread with is_Named_thread should fix this test failure.
30-08-2018
It might require -Xcomp. Seems to have turned up in tier4 and higher.
30-08-2018
JDK-8203948 was intended to address this problem. Not sure why it's showing up now. I didn't see this failure in my testing of JDK-8072498, even though I ran the relevant tiers.
30-08-2018
Problem listed with JDK-8210167. Please remember to remove it from the problem list when the fix is pushed.
29-08-2018
I suspect this was introduced by JDK-8072498. There were only 4 changesets for jdk12-jdk.303, and I can't see this being caused by any of the other 3. Also, the only failures previous to those in jdk12-jdk.303 where by runs done by Kim, who authored JDK-8072498.
29-08-2018
I will problem list this since it fails consistently 4 times in every tier4 run.
29-08-2018

Relates :	JDK-8203948 - Expand JVMTI callback notion of "internal threads"
Relates :	JDK-8072498 - Multi-thread JNI weak reference processing