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

Gerard Ziemski gziemski at openjdk.org
Mon Aug 22 20:54:38 UTC 2022


On Mon, 22 Aug 2022 17:16:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

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

We now detect whether we had to cancel any child processes and return an error code if we do (this would fix any potential false positives, where the parent test process is free to proceed, but a child process is unable to throw any error status back at the parent, because the child itself is stuck)

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

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


More information about the jtreg-dev mailing list