|
Quick Lists
|
|
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
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |