RFR: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults

Andrew Haley aph at redhat.com
Mon Dec 31 12:39:43 UTC 2018


On 12/28/18 3:06 AM, Nick Gasson (Arm Technology China) wrote:

> Please review a one-line fix to prevent a JVMTI PopFrame crash on AArch64:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215951
> Webrev: http://cr.openjdk.java.net/~njian/8215951/webrev.0/
> This jtreg test started intermittently failing on AArch64 with a 
> segfault after 8215425:
>    http://hg.openjdk.java.net/jdk/jdk/rev/1e213c37befa
> (There is a full crash log attached to the bug.)
> The faulting instruction is the load of the dispatch table pointer from 
> rdispatch (x21) in InterpreterMacroAssembler::dispatch_base.
>    0x0000ffff8c939ab8: ldrb   w8, [x22, #0]!
>    0x0000ffff8c939abc: add    w9, w8, #0x900
>    0x0000ffff8c939ac0: ldr    x9, [x21, w9, uxtw #3]   <------
>    0x0000ffff8c939ac4: br     x9
> When deoptimising a frame that has a JVMTI PopFrame event pending, 
> vframeArrayElement::unpack_on_stack will set the return PC of the 
> deoptimised frame to the the interpreter entry point 
> remove_activation_preserving_args_entry. After the PopFrame handling 
> this calls dispatch_next to dispatch the next opcode, but at this point 
> rdispatch may not have been initialised to point at the dispatch table. 
> Fix by calling get_dispatch() to initialise rdispatch at the same time 
> as the rest of the interpreter state is restored in 
> remove_activation_preserving_args_entry.
> I guess this has always been a potential problem, but adding the prints 
> in the changeset above changed the timing of when a method was compiled 
> and exposed it?

That's hard to say without a lot of analysis. In any case, your patch looks
fine. We'll want to add it to the list of jdk8 backports.

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-dev mailing list