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
