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

[Man Cao]

On Thu, 8 Sep 2022 08:19:47 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:
> 
>   Move jdk_misc_signal_init() earlier and clarify its comment

Moved `jdk_misc_signal_init()` earlier as Thomas suggested. Now that libjsig can prevent user overriding SIGBREAK later.
For Windows, `jdk_misc_signal_init()` seems appropriate as there's a `SetConsoleCtrlHandler()` above.

>  Why do you insist to move jdk_misc_signal_init() before install_signal_handlers()? Is there any difference before and after it?

Because SIGBREAK's UserHandler() uses the `pending_signals` and `sig_semaphore` variables initialized by `jdk_misc_signal_init()`.

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

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