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

Xin Liu xliu at openjdk.java.net
Thu Jan 20 20:14:52 UTC 2022


On Thu, 20 Jan 2022 07:00:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove log_info from the signal handler.
>
> 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.

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

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


More information about the serviceability-dev mailing list