JDK-6543863 : (fc) FileLock.release can deadlock with FileChannel.close
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2007-04-09
  • Updated: 2013-07-08
  • Resolved: 2009-04-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u71Fixed 7 b57Fixed
Related Reports
Duplicate :  
JDK-8015048 - Need backport of JDK-6543863 in jdk 6
Description
FULL PRODUCT VERSION :
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b10)
Java HotSpot(TM) 64-Bit Server VM (build 1.7.0-ea-b10, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux tidore 2.6.19-gentoo-r5 #1 SMP Thu Feb 15 12:11:59 CET 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux


A DESCRIPTION OF THE PROBLEM :
My application happened to call RandomAccessFile.close() and FileLock.release() on a lock created from the FileChannel of the RandomAccessFile in two different threads at the same time. This resulted in a Java  level deadlock as shown by the jstack output below.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Sorry, no steps. But it is obvious from the jstack output which locks can be acquired in inconsitent order.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Found one Java-level deadlock:
=============================
"checkpointer":
  waiting to lock monitor 0x00002aaac3b759f0 (object 0x00002aaac2c10958, a java.util.ArrayList),
  which is held by "main"
"main":
  waiting to lock monitor 0x00002aaac3b75600 (object 0x00002aaac2c109a0, a sun.nio.ch.FileLockImpl),
  which is held by "checkpointer"

Java stack information for the threads listed above:
===================================================
"checkpointer":
        at sun.nio.ch.FileChannelImpl$SharedFileLockTable.remove(FileChannelImpl.java:1128)
        - waiting to lock <0x00002aaac2c10958> (a java.util.ArrayList)
        at sun.nio.ch.FileChannelImpl.release(FileChannelImpl.java:925)
        at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:38)
        - locked <0x00002aaac2c109a0> (a sun.nio.ch.FileLockImpl)

"main":
        at sun.nio.ch.FileLockImpl.invalidate(FileLockImpl.java:31)
        - waiting to lock <0x00002aaac2c109a0> (a sun.nio.ch.FileLockImpl)
        at sun.nio.ch.FileChannelImpl$1.release(FileChannelImpl.java:106)
        at sun.nio.ch.FileChannelImpl$SharedFileLockTable.removeAll(FileChannelImpl.java:1155)
        - locked <0x00002aaac2c10958> (a java.util.ArrayList)
        at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:104)
        at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
        - locked <0x00002aaac2c1f4a8> (a java.lang.Object)
        at java.io.RandomAccessFile.close(RandomAccessFile.java:568)


REPRODUCIBILITY :
This bug can be reproduced occasionally.
Comments
EVALUATION Yes, this is a bug as the monitor for the FileLock and the lock list are acquired in different orders. The fix turns out to be simple (probably jdk7 b24). Once it has baked for a bit we examine including this fix in a 6.0 update aswell.
09-04-2007