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

Man Cao manc at openjdk.org
Mon Aug 22 08:16:52 UTC 2022


On Sun, 21 Aug 2022 06:46:11 GMT, Xin Liu <xliu 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
>
> test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java line 51:
> 
>> 49: import jdk.test.lib.process.ProcessTools;
>> 50: import jdk.test.lib.process.OutputAnalyzer;
>> 51: import vm.share.ProcessUtils;
> 
> Can we reference vmTestbase in jtreg test? I search runtime and other directories,  this is the first case to do so. 
> 
> How about we implement 'ProcessTools.sendCtrlBreak(Process)' in test/lib? We can leave it unimplemented on Windows.
> 
> Not only it can test your case, but it could also test JDK-8279124. Options like `-Xms8g -XX:+AlwaysPreTouch -XX:ParallelGCThreads=1 -Xlog:gc+heap=debug` at least takes 5s. Parent process can send SIGQUIT and check whether JVM intercepts it.

There are a few serviceability dcmd jtreg tests that already depend on /vmTestbase:
- test/hotspot/jtreg/serviceability/dcmd/framework/HelpTest.java
- test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java
- test/hotspot/jtreg/serviceability/dcmd/framework/Invalidcommandtest.java

Is there a real downside to depend on /vmTestbase?

Agree that it is a good suggestion to add a parameter to ProcessTools.sendCtrlBreak() and move it to test/lib. This function is only used in one other place datadumpreq001.java, so it's probably easy to change.
However, it's probably better to make a separate test-only RFE to move this function and add a test for JDK-8279124 together.

> test/hotspot/jtreg/runtime/Thread/TestBreakSignalThreadDump.java line 56:
> 
>> 54: 
>> 55:     static class TestProcess {
>> 56: 	static {
> 
> It looks like you embed 'tab' rather than 'whitespaces'.

Sorry, I used wrong coding style for formatter. Fixed.

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

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


More information about the hotspot-runtime-dev mailing list