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

[Xin Liu]

On Mon, 22 Aug 2022 08:12:40 GMT, Man Cao <manc at openjdk.org> wrote:

>> 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.

make sense.

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

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