Diagnosis when sub-JVM process fails catastrophically

[Jonathan Gibbons]

Part of the problem is that jtreg may be used on older JDK releases and 
so cannot rely on the latest and greatest API. To work around that, 
jtreg now supports the use of a "process helper" to diagnose the sort of 
cases you're talking about. IIRC, this is used in the JDK makefiles for 
the JDK and Hotspot tests. (LangTools hasn't had the same problem.)

Note that you can also use the -retain option to save some or all files 
from some or all tests, including hserr files etc.

-- Jon

On 11/14/17 9:15 AM, Martin Buchholz wrote:
> If an inferior java process fails while running tests, jtreg is often
> unhelpful.  E.g. we might get SocketTimeoutException, or if the test itself
> spawns a sub-process we might get Exit Code 139, with no more details.  But
> there's a good chance that there's diagnostic information provided, perhaps
> in an hs_errpid file.  Maybe those files should be looked for.  Maybe we
> should invoke java with a flag like -XX:ErrorFile:/dev/stderr.  Maybe we
> should be fixing jtreg itself (when spawning "other" VM or agent VMs) and
> also JDK's own test library's helpers that spawn subprocesses.  At Google,
> we see a background noise of failing tests that go undiagnosed, and
> Oracle's tests seem to have the same problem.