RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat (original) (raw)

Ivan Gerasimov ivan.gerasimov at oracle.com
Wed Mar 19 14:34:57 UTC 2014

Thanks Alan!

These two tests used the commands run from non very common location (/usr/bin/ instead of /bin/), so I suspect they have been rarely run. As it follows from the summaries, one of them ensures the VM doesn't crash; the other checks, whether the input/output streams are left open. Both tests in the case of a failure could interfere with other tests unless they run in the othervm mode. That's why I thought it's better to add the flag. If a test is badly behaved and is leaving streams open then I would agree with othervm. However these are old issues (right?) and should not be happening now. Also if a test tickles a bug that causes the VM to crash then jtreg will spin up a new VM for the next test. So if it's possible to avoid othervm then we should (and from what I can tell then these tests have been well behaved when running without othervm before). Yes, got it. I will remove othervm mode.

Once I was suggested to add the othervm mode to the test which was to detect a memory leak (in the case of a poor behavior). So I was under wrong impression that we need to use this mode even when normal run of a test doesn't influence any other.

Omitting othervm for the tests that do not interfere with others during normal runs does make sense, and I will follow this rule from now on.

IMO ideally, there should be a configurable part of the harness, where all the shell commands are set up. So that they could be accessed by both Java and shell-based regtests. test/lib/testlibrary is the place for test-suite wide infrastructure. I don't know if there are tests beyond the Process area that needs to do the same kind of thing. I meant something that can be configured by a user of the harness. It's beyond the scope of this bug, of course.

Sincerely yours, Ivan

More information about the core-libs-dev mailing list