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