Yeah, I think if your double close check works, then the proper fix
really should be to rework the original implementation of JDK-8222491 so
no double close is done.
Chris
On 6/17/19 12:23 PM, Gary Adams wrote:
https://bugs.openjdk.java.net/browse/JDK-8224642
I may have a handle on what is going wrong with the
TestJcmdSanity test and the bad file descriptor.
A change made in April 2019 placed the input stream and reader
within the same try with resources block. This has the effect of
calling the
SocketInputStream close method twice for each command processed.
https://bugs.openjdk.java.net/browse/JDK-8222491
http://hg.openjdk.java.net/jdk/jdk/rev/4224f26b2e7f
The last set of tests in the TestJcmdSanity test attempts to process ~100
VM.version commands in a loop. Since the closes are handled
when the objects are collected it may come at an inopportune time.
I'm testing the fix below to ensure a second close becomes a noop.
It may be better to revisit the earlier change that set up the double
close calls.
diff --git
a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
---
a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++
b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -233,7 +233,7 @@
* InputStream for the socket connection to get target VM
*/
private class SocketInputStream extends InputStream {
- int s;
+ int s = -1;
public SocketInputStream(int s) {
this.s = s;
@@ -261,7 +261,10 @@
}
public void close() throws IOException {
+ if (s != -1) {
VirtualMachineImpl.close(s);
+ s = -1;
+ }
}
}
