RFR  TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat
ivan.gerasimov at oracle.com
Wed Mar 19 14:34:57 UTC 2014
>> 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.
More information about the core-libs-dev