RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address

Gustavo Romero gromero at linux.vnet.ibm.com
Sun Mar 24 19:12:15 UTC 2019

Hi Thomas,

On 03/22/2019 02:18 PM, Thomas Stüfe wrote:
> Hi Gustavo,
> Just a question, is the other case where we replace si_addr with
> address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc);
> really needed? Since we use si_addr in a number of places and I always assumed that just works like on every other posix system.

This a good point, Thomas. If si_addr had always worked on Linux I understand
that get_stack_band_address() would have never existed and the signal handler
would not have to discern between data and instruction interruptions at all.

By the comments and logs it looks like si_addr was broken before kernel 2.6.6
(quite old) which afaics is not currently supported by any distros anymore.
So get_stack_bang_address() in the past was necessary, but not anymore, since
long time, thus relying on si_addr in other places you pointed out worked
well so far and will continues to work.

We could switch the code to trust si_addr only, since I believe there is no real
impact nowadays. But in theory it can be a regression... ?

Thomas and Goetz: which approach do you suggest here? Please, advise.

Thank you.

Best regards,
> E.g. we use it for assertion poison page handling or handling of secondary crashes during error reporting, see handle_assert_poison_fault().
> Cheers, Thomas
> On Fri, Mar 22, 2019 at 4:29 PM Gustavo Romero <gromero at linux.vnet.ibm.com <mailto:gromero at linux.vnet.ibm.com>> wrote:
>     Hi,
>     Please, could I get reviews for the following change:
>     bug   : https://bugs.openjdk.java.net/browse/JDK-8220794
>     webrev: http://cr.openjdk.java.net/~gromero/8220794/v1/ <http://cr.openjdk.java.net/%7Egromero/8220794/v1/>
>     It fixes the JVM signal handler on Linux / PPC64 when a SIGSEGV generated
>     by a branch to an illegal/invalid address (not mapped address, address with no
>     executable flags, etc) is caught by the JVM signal handler. Currently the signal
>     handler does not handle that case correctly and the JVM crashes silently.
>     That issue was reported by Goetz (SAP). Thanks for reporting the issue, Goetz.
>     Thank you.
>     Best regards,
>     Gustavo

More information about the hotspot-runtime-dev mailing list