-
Bug
-
Resolution: Duplicate
-
P2
-
6
-
x86
-
windows_xp
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2183925 | 6u18 | Pavel Porvatov | P2 | Closed | Fixed | b04 |
JDK-2185615 | 6u17-rev | Nikolay Gorshkov | P2 | Closed | Fixed | b08 |
FULL PRODUCT VERSION :
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
EXTRA RELEVANT SYSTEM CONFIGURATION :
NTFS file system
A DESCRIPTION OF THE PROBLEM :
Win32ShellFolderManager2 deadlocks on it's own ComInvoker. See relevant stack traces:
"AWT-EventQueue-2" prio=4 tid=0x0674d000 nid=0x1730 waiting on condition [0x097ae000..0x097afd14]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x203d2440> (a java.util.concurrent.FutureTask$Sync)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.hasAttribute(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.isLink(Unknown Source)
- locked <0x20342290> (a sun.awt.shell.Win32ShellFolder2)
at javax.swing.filechooser.FileSystemView.isFileSystem(Unknown Source)
at javax.swing.filechooser.FileSystemView.getSystemDisplayName(Unknown Source)
at javax.swing.plaf.basic.BasicFileChooserUI$BasicFileView.getName(Unknown Source)
at javax.swing.JFileChooser.getName(Unknown Source)
...
and
"Swing-Shell" daemon prio=4 tid=0x0a178400 nid=0x1214 waiting for monitor entry [0x0279f000..0x0279fd94]
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.awt.shell.Win32ShellFolder2.isFileSystem(Unknown Source)
- waiting to lock <0x20342290> (a sun.awt.shell.Win32ShellFolder2)
at sun.awt.shell.Win32ShellFolder2.equals(Unknown Source)
at java.util.AbstractList.equals(Unknown Source)
at java.util.Vector.equals(Unknown Source)
- locked <0x202aac10> (a java.util.Vector)
at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread$1.call(Unknown Source)
at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
-----
The Win32ShellFolder2 locks the object monitor in isFileSystem, then waits for the com invoker to finish (future.get()). However the com invoker (Swing-Shell thread) tries to use the Win32ShellFolder2.isFileSystem(), which causes the deadlock.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open a JFileChooser in JRE 1.6.0_07
REPRODUCIBILITY :
This bug can be reproduced often.
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
EXTRA RELEVANT SYSTEM CONFIGURATION :
NTFS file system
A DESCRIPTION OF THE PROBLEM :
Win32ShellFolderManager2 deadlocks on it's own ComInvoker. See relevant stack traces:
"AWT-EventQueue-2" prio=4 tid=0x0674d000 nid=0x1730 waiting on condition [0x097ae000..0x097afd14]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x203d2440> (a java.util.concurrent.FutureTask$Sync)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.hasAttribute(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.isLink(Unknown Source)
- locked <0x20342290> (a sun.awt.shell.Win32ShellFolder2)
at javax.swing.filechooser.FileSystemView.isFileSystem(Unknown Source)
at javax.swing.filechooser.FileSystemView.getSystemDisplayName(Unknown Source)
at javax.swing.plaf.basic.BasicFileChooserUI$BasicFileView.getName(Unknown Source)
at javax.swing.JFileChooser.getName(Unknown Source)
...
and
"Swing-Shell" daemon prio=4 tid=0x0a178400 nid=0x1214 waiting for monitor entry [0x0279f000..0x0279fd94]
java.lang.Thread.State: BLOCKED (on object monitor)
at sun.awt.shell.Win32ShellFolder2.isFileSystem(Unknown Source)
- waiting to lock <0x20342290> (a sun.awt.shell.Win32ShellFolder2)
at sun.awt.shell.Win32ShellFolder2.equals(Unknown Source)
at java.util.AbstractList.equals(Unknown Source)
at java.util.Vector.equals(Unknown Source)
- locked <0x202aac10> (a java.util.Vector)
at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread$1.call(Unknown Source)
at javax.swing.plaf.basic.BasicDirectoryModel$LoadFilesThread$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
-----
The Win32ShellFolder2 locks the object monitor in isFileSystem, then waits for the com invoker to finish (future.get()). However the com invoker (Swing-Shell thread) tries to use the Win32ShellFolder2.isFileSystem(), which causes the deadlock.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open a JFileChooser in JRE 1.6.0_07
REPRODUCIBILITY :
This bug can be reproduced often.
- backported by
-
JDK-2183925 Deadlock in Win32ShellFolderManager2
- Closed
-
JDK-2185615 Deadlock in Win32ShellFolderManager2
- Closed
- duplicates
-
JDK-6713352 Deadlock in JFileChooser with synchronized custom FileSystemView
- Closed
- relates to
-
JDK-6892340 Part of the CR 6741890 should be forwardported
- Closed