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

Thomas Stuefe stuefe at openjdk.org
Wed Sep 7 14:08:40 UTC 2022


On Wed, 7 Sep 2022 06:53:12 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
>
> Thanks for filing the other bug. Responded in that bug.

Looking at this, this gets more and more interesting. One thing, libjsig does nothing to prevent user code from changing thread/process sigmask. @caoman has that never been a problem at Google?

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

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


More information about the hotspot-runtime-dev mailing list