RFR(XS): 8193308: Disallow installing user signal handlers for SIGBUS on OSX

Thomas Stüfe thomas.stuefe at gmail.com
Sat Feb 10 10:54:35 UTC 2018


Hi Mandy,

On Fri, Feb 9, 2018 at 11:59 PM, mandy chung <mandy.chung at oracle.com> wrote:

> Hi Robin, As documented in [1], SIGBUS is listed as the signals used by
> the HotSpot implementation. It could be just that it was missed from day
> 1.Have you checked the native signal chaining support via libjsig.so? It
> should disallow to install a user native signal handler for SIGBUS.


Why? It is still a valid scenario for the VM to hand down unhandled
SIGSEGV, SIGBUS etc to a user handler. For instance, if the VM is embedded
and the surrounding user program rolls or a native library in it rolls its
own error handling, and the user prefers that one to the hs-err files we
print. This is actually not exotic at all, we have embedders who handle
error signals to do cleanups or silent crash mitigation.

Signal chaining would not prevent us from handling any signal - VM still
has first dibs - but would give a user handler opportunity to do so too if
we choose not to consume the signal.

Kind Regards, Thomas

I think JVM_RegisterSignal should disallow installing a user handler for
> one of the implementation-specific signals for all platforms. That'll
> simplify your fix. I would think the compatibility risk should be low as
> rare cases would want to intercept SIGBUS which is also clearly documented
> in [1]. Mandy [1] https://docs.oracle.com/javase
> /9/troubleshoot/handle-signals-and-exceptions.htm#JSTGD356 On 7/02/2018
> 1:19 AM, Robin Westberg wrote: > Hi all, > > Please review the following
> change to disallow installing user > signal handlers for SIGBUS on OSX. On
> OSX, SIGBUS is used > internally by the VM (where most other platforms only
> use SIGSEGV), > and installing a user handler can lead to a deadlock. > >
> Issue: https://bugs.openjdk.java.net/browse/JDK-8193308 > Webrev:
> http://cr.openjdk.java.net/~rwestberg/8193308/webrev.00/ > > Best
> regards, > Robin
>
>


More information about the hotspot-runtime-dev mailing list