RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace()
Baesken, Matthias
matthias.baesken at sap.com
Fri Aug 9 13:56:58 UTC 2019
Hello, please review this small test adjustment .
The TestShutdownEvent.java JFR test fails now and then in the sub-test "TestVMCrash" .
Error is in the stack validation , it finds sometimes a stack with no frames .
at jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128)
at jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172)
Our conclusion so far is that it is currently not 100% reliable to get a stack trace in this case using vframeStream in jfrStackTraceRepository.cpp
(forced crash with Unsafe + event generation using EventShutdown late in VMError.cpp ) .
Reason is that we might get compiled frames on the stack and then the vframeStream - based solution does not work ( when running with -Xcomp it always fails).
See also the comments of our JIT expert Martin in the bug :
"JfrStackTrace uses vframeStream to retrieve the stack frames.
This works fine if a native frame is on top (because we have the last Java frame linked in the JavaThread object).
That's why the tests works when executed with -Xint. The crashing method is native in this case.
The situation is different when there's a compiled frame on top.
JIT compilers usually inline Unsafe accesses as instrinsics. So the crashing instruction is just in the middle of a compiled method.
The vframeStream API would require a PC for which additional information is available (see CodeEmitInfo for C1 or JVMState for C2).
That's not the case for an illegal Unsafe access which simply yields undefined behavior. Vframes are not supported in this case so the stack trace is empty.
It is possible to get a native stack trace (see VMError::print_native_stack which doesn't use vframes) for hs_err files. Compiled frames are only shown as single
frames even if multiple Java frames are included due to inlining.
Note that the test always fails when using -Xcomp. So it doesn't make any sense to expect a non-empty vframe based stack trace when a compiled frame is on top. "
My first idea was to run the test with -Xint but its probably not such a good idea ; so better for now remove the unreliable check ( + add a comment ).
Thanks, Matthias
Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8219082
http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/
More information about the hotspot-dev
mailing list