RFR: 8254668: JVMTI process frames on thread without started processing

[Erik Österlund]

On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I hit the following assert in some tests runs that I've been doing:
> # Internal Error (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67), pid=828170,
> tid=828734 # assert(processing_started()) failed: Processing should already have started
> 
> The stack traces for this has been:
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x1626d75] StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5
> V [libjvm.so+0xad791a] frame::sender(RegisterMap*) const+0x7a
> V [libjvm.so+0xacd3f8] frame::real_sender(RegisterMap*) const+0x18
> V [libjvm.so+0x1804c4a] vframe::sender() const+0xea
> V [libjvm.so+0x175f47b] JavaThread::last_java_vframe(RegisterMap*)+0x5b
> V [libjvm.so+0x10e10fc] JvmtiEnvBase::vframeFor(JavaThread*, int)+0x4c
> V [libjvm.so+0x10e6972] JvmtiEnvBase::check_top_frame(Thread*, JavaThread*, jvalue, TosState, Handle*)+0xe2
> V [libjvm.so+0x10e759c] JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x11c
> V [libjvm.so+0x105b8f5] jvmti_ForceEarlyReturnObject+0x215
> V  [libjvm.so+0x1626d75]  StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xd5
> V  [libjvm.so+0xad791a]  frame::sender(RegisterMap*) const+0x7a
> V  [libjvm.so+0xacd3f8]  frame::real_sender(RegisterMap*) const+0x18
> V  [libjvm.so+0x1804c4a]  vframe::sender() const+0xea
> V  [libjvm.so+0x1804d00]  vframe::java_sender() const+0x10
> V  [libjvm.so+0x10e1115]  JvmtiEnvBase::vframeFor(JavaThread*, int)+0x65
> V  [libjvm.so+0x10d475f]  JvmtiEnv::NotifyFramePop(JavaThread*, int)+0x9f
> V  [libjvm.so+0x106b6aa]  jvmti_NotifyFramePop+0x23a
> The code inspects the top frame of a suspended java thread. However, there's nothing in the code that starts the
> watermark processing of the thread, so the code asserts when sender calls on_iteration.
> We only have to call start_processing/on_iteration when oops are being read. The failing code does *not* inspect any
> oops, so I turn of the on_iteration call by settings process_frame to false.
> To notify the readers of the code that vframeFor doesn't process the oops, I've renamed the function to
> vframeForNoProcess to give a visual cue.
> I found this bug when running this command line:
> makec ../build/fastdebug/ test TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti
> JTREG="JAVA_OPTIONS=-XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=1 -XX:ZFragmentationLimit=0.01"
> JTREG_EXTRA_PROBLEM_LISTS=ProblemList-zgc.txt   Five tests consistently asserts with this command line. All tests pass
> with the proposed fix.
> Recommendations of tests to run are welcome. I intend to get this run through tier1-3, but haven't yet.

Looks good. Thanks for fixing this.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/627