RFR: 8279124: VM does not handle SIGQUIT during initialization [v5]

[David Holmes]

On Thu, 20 Jan 2022 20:11:43 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/os/posix/signals_posix.cpp line 600:
>> 
>>> 598:     assert(!ReduceSignalUsage, "Should not happen with -Xrs/-XX:+ReduceSignalUsage");
>>> 599:     signal_was_handled = true;
>>> 600:   }
>> 
>> Can't we just do this as the very first thing at line 564:
>> 
>> // If we get BREAK_SIGNAL it means we are very early in VM initialization and 
>> // only temporarily "handling" it to prevent the VM process getting terminated.
>> if (sig == BREAK_SIGNAL) {
>>   assert(!ReduceSignalUsage, "Should not happen with -Xrs/-XX:+ReduceSignalUsage");
>>   return true;
>> }
>
> hi, David and Thomas, 
> 
> I am nervous about this change. It's not complex but I don't want to break the existing java applications. Bear with me. 
> 
> From my reading, HotSpot can chain a user-custom signal handler because of libjsig.so.  It's not like a linked-list chain. if the user installs a handler for a signal, libjsig just saves it. JVM_HANDLE_XXX_SIGNAL is invoked first and then the user-custom handler is called [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L635) if it isn't handled.
> 
> The reason we can hoist this logic to line 564 because we **assume** that no user application would define a handler for BREAK_SIGNAL.  It doesn't work right now because os::initialize_jdk_signal_support() will overwrite the signal handler of BREAK_SIGNAL later.

Hi Xin,
Signal chaining doesn't work for BREAK_SIGNAL - from the signal chaining docs:


Note:

The SIGQUIT, SIGTERM, SIGINT, and SIGHUP signals cannot be chained. If the application must 
handle these signals, then consider using the —Xrs option.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7003