JDK-6741890 : Deadlock in Win32ShellFolderManager2
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-08-27
  • Updated: 2011-02-16
  • Resolved: 2009-05-15
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
6u17-revFixed 7Resolved
Related Reports
Duplicate :  
Relates :  
Description
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.

Comments
EVALUATION It is difficult to evaluate this bug without provided test case, "Open a JFileChooser in JRE 1.6.0_07" allows different interpretation e.g. the deadlock is pretty possible when Swing components are incorrectly created or used outside Event Dispatch Thread assigned to JFileChooser owner
27-08-2008