RFR: 8292695: SIGQUIT and jcmd attaching mechanism does not work with signal chaining library [v4]

[David Holmes]

On Fri, 9 Sep 2022 08:27:41 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this bug fix? See https://bugs.openjdk.org/browse/JDK-8292695 for details.
>> 
>> I changed the temporary handler for SIGQUIT to use a dummy function, and use `os::signal()` to set it up, just as `os::initialize_jdk_signal_support()` does.
>> It is possible that just moving the `set_signal_handler(BREAK_SIGNAL, false);` in `install_signal_handlers()` outside of the window bounded by `JVM_{begin|end}_signal_setting()` could also fix this bug. However, `set_signal_handler()` and `JVM_HANDLE_XXX_SIGNAL()` are currently used for signals that support chaining and periodically check, which do not apply to SIGQUIT. I think it is cleaner to use different functions for SIGQUIT.
>> 
>> I also added a test to check that sending SIGQUIT should produce a thread dump on stdout, with and without using libjsig.so.
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments in test

I don't really agree with the rationale, but the fix is correct, and the reordering seems harmless enough on further inspection.

To me this is a JDK serviceability signal, both for dynamic attach and thread dumps, as it is the JDK serving "signal thread" that handles it. Most of the problems in this area have stemmed from initialization issues due to "too early" sending of SIGQUIT to initiate an attach attempt.

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

PR: https://git.openjdk.org/jdk/pull/9955