RFR: 7903217: jtreg could try killing descendants of stuck test, before timing out the test

Gerard Ziemski gziemski at openjdk.org
Mon Aug 22 17:21:34 UTC 2022


On Thu, 11 Aug 2022 20:40:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is an enhancement that aims to improve the robustness of the testing by attempting to quit any child processes (that are possibly stuck and are blocking the parent process from terminating) before timing out the target parent process.
>> 
>> Aborting a process will flush its stdout/stderr streams, which will hopefully get captured in the test's log and provide additional clues as to why a test was timing out.
>> 
>> This enhancement was locally tested with a handcrafted test that itself launched a child process that would get stuck on purpose and worked as intended.
>> 
>> Hopefully, this will help debug issues such as [JDK-8286345](https://bugs.openjdk.org/browse/JDK-8286345)
>
> src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java line 307:
> 
>> 305:                 alarm.cancel();
>> 306: 
>> 307:                 return getStatus(exitCode, statusScanner.exitStatus());
> 
> I think you need to do something more here.   If the class killed child processes, you need to ensure that (probably) `Status.error` is returned with a suitable string. In other words, consider the case where you unlock a child process and the main process exits normally for some reason. That should *not* be grounds for the test to pass.

I see the point, but I also had a case where after force quitting the child process, the parent test process is able to retrieve everything it needed from the child (which finished its task required for the parent before getting itself locked up) and be able to succeed just fine.

If we were to return error code in such cases, we would be generating failures in cases where the parent process was able to finish, but its children were not. Not necessarily always directly related to the case under test, more of a tangential failure, but I do see the value in reporting such cases. I will tweak it then.

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

PR: https://git.openjdk.org/jtreg/pull/97


More information about the jtreg-dev mailing list