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

Thomas Stüfe thomas.stuefe at gmail.com
Sat Feb 10 11:13:18 UTC 2018


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.

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