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