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. Also a minor point but it might be more readable if the body of
the for statement was indented.
-Alan.
