RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace()

[mikhailo.seledtsov at oracle.com]

Looks good to me,

Thank you,

Misha

On 8/9/19 6:56 AM, Baesken, Matthias wrote:
>
> 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/
>