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

[mandy chung]

Hi Thomas,

On 2/10/18 3:13 AM, Thomas Stüfe wrote:
>
>
> On Sat, Feb 10, 2018 at 11:54 AM, Thomas Stüfe 
> <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi Mandy,
>
>     On Fri, Feb 9, 2018 at 11:59 PM, mandy chung
>     <mandy.chung at oracle.com <mailto: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
>
>
> In addition to that I now wonder what "disallow SIGBUS for signal 
> chaining" even means.
>
> Should the "signal()" function in libjsig return an error if the user 
> code attempts to install a signal handler for SIGBUS? That would break 
> existing user programs and confuse developers who think they call 
> standard POSIX signal() which now suddenly returns an error for no 
> reason.
>
> Or should we just silently ignore the attempt to install this signal 
> and just not do anything about it - so, not handing down error signals 
> to the chainee if we do not consume them? I guess we could that, but 
> why? The whole point of signal chaining is to allow user handlers to 
> handle signals we catch first but don't want. If we stop handing down 
> the uncomsumed error signals, why even bother with signal chaining at 
> all?
>
> JVM_RegisterSignal: this only affects sun.misc.Signal and has nothing 
> to do with signal chaining, or? I lean toward Davids opinion here, I 
> would handle this list on a per platform base.

I probably have a wrong assumption of what libjsig.so is doing and 
incorrectly tie it with sun.misc.Signal.   In any case, I was trying to 
point out the existence of libsig.so and make sure if it's also impacted 
or nothing to do there.

About JVM_RegisterSignal, it's a VM internal interface used by the 
library.  It's okay for the Java API to do the filtering and as David 
replied, keep this change as macOS-specific fix.

thanks
Mandy