RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows

Ivan Gerasimov ivan.gerasimov at oracle.com
Sat Sep 14 18:58:32 UTC 2013

On 12.09.2013 19:21, Alan Bateman wrote:
> On 12/09/2013 06:59, Ivan Gerasimov wrote:
>> Hello Alan, Martin, everyone!
>> Some update on the issue.
>> When trying to integrate my test into Basic.java, I found that it 
>> already contains exactly the same.
>> I have just overlooked it before.
>> Additional investigation showed that inheritIO() doesn't always fail 
>> on Windows.
>> If the scenario is like following:
>> - java application creates a child java process (no IO inheritance, 
>> redirecting IO through pipes by default),
>> - child process creates a grandchild which inherits the child's 
>> stdin/out/err,
>> everything works as expected.
>> However, if the java app (started from a console) creates an 
>> immediate child that inherits its parent stdin/out/err, it fails.
>> That's why this bug hasn't been caught by Basic.java before - because 
>> it uses the first testing scenario.
>> And that's why I had to introduce a new shell script test - because 
>> the problem couldn't be reproduced otherwise.
>> Would you please review the updated webrev?
>> http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ 
>> <http://cr.openjdk.java.net/%7Eigerasim/8023130/1/webrev/>
> Based on the previous mails then the update to ProcessImpl_md.c seems 
> right. It's probably best to give this one some bake time in jdk8 
> before you backport it to jdk7u-dev. The reason is that the Process 
> code likes to bite back when it is changed.
> On the tests then you probably know we don't like shell tests because 
> they are usually slower and statistically more troublesome. Given the 
> scenario that you are trying to test (and it's useful that you've got 
> to the bottom of the issue) there they may not be other options here. 
> One small concern with the shell test as it stands is that it looks 
> like it is depend on the exact output. This makes me wonder about how 
> it will behave with a debug or fastdebug build that might have 
> additional output.

I only changed the way the test is called.
When the same test is run from Basic.java, it's also expected to receive 
some certain output.
So I think that if it worked well from Basic.java, it should also work 
from the shell script.

> Also a minor point but it might be more readable if the body of the 
> for statement was indented.
Yes, done.

Would you please review the updated webrev?

Sincerely yours,

> -Alan.

More information about the core-libs-dev mailing list