Diagnosis when sub-JVM process fails catastrophically

Thomas Stüfe thomas.stuefe at gmail.com
Tue Nov 14 19:10:14 UTC 2017


At SAP, after a test runs, we just collect any and all hs-err files
generated and upload them to our test database. This is not jtreg though,
this is our own test infrastructure.

Kind Regards, Thomas

On Tue, Nov 14, 2017 at 6:15 PM, Martin Buchholz <martinrb at google.com>
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.
>


More information about the jtreg-dev mailing list