RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows
Ivan Gerasimov
ivan.gerasimov at oracle.com
Tue Sep 17 13:22:49 UTC 2013
Hi Alan!
On 15.09.2013 23:49, Alan Bateman wrote:
> On 15/09/2013 12:06, Ivan Gerasimov wrote:
>> :
>>
>> I decided to check whether this test really detects the failure, and
>> run JPRT job with the new test but no fix included.
>> Unfortunately, the new test *does not* fail with unmodified jdk.
>> The same thing happens when the test is run with jtreg locally.
>> I believe it is so, because the tested program is run not directly
>> from a console, and this is the condition for the bug to manifest itself.
>>
>> So I have to exclude the test, as it really doesn't check anything new.
>> I'm going to add noreg label and write an instruction to the QA about
>> how to test the fix manually.
>>
>> What is good is that we don't need another shell-based test.
>>
>> Here's the new webrev:
>> http://cr.openjdk.java.net/~igerasim/8023130/3/webrev/
>> <http://cr.openjdk.java.net/%7Eigerasim/8023130/3/webrev/>
>> Its only difference is that the shell script is excluded.
> JPRT may be using ssh but others will likely run the tests in other
> configurations. If the shell test allows the scenario to be tested in
> other configurations then it may be better to just include it in your
> patch (in general we want to eliminate as many shell tests as possible
> but a shell tests bets the cost of a manual test any day).
I totally agree with you that any automated test is better than any manual.
The problem is that I couldn't make the test fail no matter how I
invoked it - from JPRT, from a locally running jtreg or even from plain
cygwin.
The only way I could reproduce the problem with unpatched jdk was to run
the test application directly from a Windows console.
Sincerely yours,
Ivan
>
> -Alan.
More information about the core-libs-dev
mailing list