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

[Thomas Stüfe]

Hi Mandy,

On Tue, Feb 13, 2018 at 5:51 PM, mandy chung <mandy.chung at oracle.com> wrote:

> 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>
> wrote:
>
>> 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
>>
>>
> 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.
>
>
Ah, okay. Yes, two different animals, and I think libjsig.so could stay as
it is. I agree with you on that catching SIGBUS with sun.misc.Signal is not
useful. I doubt it is even possible.


> 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.
>

That makes sense.

Thank you,

Thomas


>
> thanks
> Mandy
>