JDK-8204555 : files might be closed by multiple threads (unix)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2018-06-07
  • Updated: 2018-06-12
  • Resolved: 2018-06-12
Related Reports
Relates :  
JDK-8204663 - clean up remaining native parts after JDK-8187631
Description
io_util_md.c fileClose can close the wrong file.

If two threads enter this function, both might try to close the same file descriptor.  This is dangerous, as the OS may have already reused the file descriptor after the first close for a third thread. We see this in our JRuby tests (the double close, not the bad case with the third thread).

Won't fix, see Thomas' comments.
Comments
I'll close this as duplicate as it's pointless after JDK-8187631.
11-06-2018
Yes, this is a non-issue since JDK-8187631 changed close handling in FIS/FOS. Java_java_io_FileOutputStream_close0() in the native part of FOS is a remnant, and so is fileClose in unix/io_util_md.{c|h}. Both can be removed. I opened JDK-8204663
11-06-2018
Would it be possible to start with a test case to demonstrate the issue? Was the JRuby code using the standard APIs? Also which JDK? We should try to avoid use of mutex/locks here.
07-06-2018
Hi Alan, we ran into this problem in 2011 with jruby and fixed it in SAP JVM. I had planned to fix this by using pthread_mutex_lock(). Java_java_io_FileOutputStream_close0() is dead? Then this really seems pointless as FileDescriptor.close() is synchronized.
07-06-2018
This is not the right level to deal with such bugs, it should be dealt with by the caller. Are you running into a bug in FIS, FOS, RAF?
07-06-2018