Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6543863
Votes 0
Synopsis (fc) FileLock.release can deadlock with FileChannel.close
Category java:classes_nio
Reported Against
Release Fixed 7(b57)
State 10-Fix Delivered, bug
Priority: 4-Low
Related Bugs
Submit Date 09-APR-2007
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 ( customer  0x00002aaac2c10958, a java.util.ArrayList),
  which is held by "main"
"main":
  waiting to lock monitor 0x00002aaac3b75600 ( customer  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.
Posted Date : 2007-04-09 09:45:53.0
Work Around
N/A
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.
Posted Date : 2007-09-17 11:55:04.0
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang