> 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.
Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/627/files - new: https://git.openjdk.java.net/jdk/pull/627/files/587fd354..00c1b25f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=627&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=627&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/627/head:pull/627 PR: https://git.openjdk.java.net/jdk/pull/627
