Bug description:
https://jbs.oracle.com/bugs/browse/JDK-7147084
http://bugs.sun.com/view_bug.do?bug_id=7147084
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.01/
Summary for v1 changes:
-- The set of handles that need to restore the inherit flag was extended
by child process IOE handles. That was done to avoid "greedy sibling"
problem for the file handles. The file handles are closed outside the
synchronized block.
-- "Greedy sibling" problem is covered by the
[test/java/lang/ProcessBuilder/SiblingIOEHandle.java] test.
-- The fact that the set of current process standard IOE handles and the
set of child process IOE handles can intersect was taken into account.
-- The [test/java/lang/ProcessBuilder/InheritIOEHandle.java] was changed
in accordance with Martin's concern.
Warning!
Bugs 7147084 and 6921885 have visible impact for IDE's functionality. If
they have a "hint" for the problem, the "hint" may produce the "regression".
Regards,
-uta
On 5/13/2013 6:44 PM, Alexey Utkin wrote:
Thanks, Martin!
You are right. The approach
private static String JAVA_EXE = System.getProperty("java.home")
+ File.separator + "bin"
+ File.separator + "java";
private static String[] getCommandArray(String processName) {
String[] cmdArray = {
JAVA_EXE,
"-cp",
System.getProperty("java.class.path"),
InheritIOEHandle.class.getName(),
processName
};
return cmdArray;
}
is better. There is one more problem with raise-condition for the file
handles. In current edition there is delta when the file handle could
be inherited by the concurrent process. That is not fatal for
read/write, but not good for delete. Synchronized call does not cover
the file.close in finalized block.
I will prepare new edition soon.
Regards,
-uta
On 5/8/2013 10:20 PM, Martin Buchholz wrote:
Alexey,
Thanks for working on the scary windows process stuff.
I only have time for superficial review.
It looks like you know what you're doing.
+ String[] cmdArray = {
+ "java",
+ "-cp",
This looks like it's invoking whatever "java" is on the path. But
there's no guarantee there is such a java, or that it's the right
one. Consider invoking the java we're in, as in other jtreg tests
like IIRC ProcessBuilder/Basic.java
