JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor

Chris Plummer chris.plummer at oracle.com
Mon Jun 17 20:07:13 UTC 2019


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;
> +            }
>          }
>      }




More information about the serviceability-dev mailing list