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

[David Holmes]

On 13/02/2018 12:43 AM, Roger Riggs wrote:
> Hi,
> 
> I can see allowing applications to register for synchronous signals 
> (SIGBUS) in the case
> where a handlers actions can affect the execution flow.
> 
> But for JVM_RegisterSignal, the signal is queued to a separate thread 
> which is in turn
> dispatched to yet another thread to notify the Java handler.
> 
> What is the behavior of the original thread?  If it was an instruction 
> that caused SIGBUS,
> does it get repeated?  Does the thread get killed, etc.

I don't know. But is the answer any different for SIGBUS compared to 
SIGILL, SIGFPE, ... ?

> I can't see a handler for SIGBUS or SIGSEGV being make correct or useful 
> to a java handler.

I can't see this being correct or useful for any signals that mean 
"something bad has gone wrong with your program". It's really only 
useful for communication signals IMHO: SIGUSR1, SIGUSR2, SIGINT, ...

> Maybe it is up to sun.misc.Signal to refuse to register those handlers, 
> independent of JVM_RegisterSignal.

Sure it could do that.

Cheers,
David

> Thanks, Roger
> 
> 
> On 2/11/2018 8:36 AM, David Holmes wrote:
>> On 11/02/2018 3:37 AM, mandy chung wrote:
>>> On 2/10/18 3:24 AM, David Holmes wrote:
>>>> On 10/02/2018 5:18 PM, mandy chung wrote:
>>>>>>>
>>>>>>> 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].
>>>>>>
>>>>>> Each platform defines its own set of signals that are used by the 
>>>>>> VM on that platform. While I've never thought it made any sense to 
>>>>>> attempt to install user "handlers" for SIGBUS or SIGSEGV (not that 
>>>>>> we allow the latter) others have argued that unless we use it then 
>>>>>> we should allow it. Hence no "lowest common denominator" approach 
>>>>>> - though that certainly would be simpler.
>>>>>>
>>>>>> In this case I believe it is simply another case where the OS X 
>>>>>> port copied the Linux code and it wasn't realized that OS X would 
>>>>>> generate SIGBUS when SIGSEGV is "expected" and so didn't list it 
>>>>>> as excluded.
>>>>>
>>>>> Are we agreeing on disallowing SIGBUS for all platforms?
>>>>
>>>> No. If the VM doesn't use SIGBUS on a platform then it shouldn't 
>>>> disallow it.
>>>>
>>>
>>> JVM_RegisterSignal is the VM support for sun.misc.Signal.   As it 
>>> does not make sense to install user handlers for SIGBUS, regardless 
>>> whether the VM uses it or not, I suggest to disallow it from 
>>> JVM_RegisterSignal for consistency.
>>
>> I've argued this in the past and was shot down. If the VM doesn't use 
>> a signal then it's fair game for end-user use.
>>
>> The only thing broken here was OS X and that is now fixed.
>>
>> David
>>
>>> Mandy
>