Hang in getSystemDisplayName()

[Paul J. Lucas]

I've been using JDK 1.6.0_11 and occasionally, when
FileSystemView.getSystemDisplayName() is called, it just hangs. Below is an
excerpt of a thread-dump. Any ideas?

- Paul


"Thread-7" prio=6 tid=0x010e4c00 nid=0xdb0 waiting on condition
[0x29a8e000..0x29a8fb14]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x05d63708> (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.getFileSystemPath(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.composePathForCsidl(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.<init>(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2.getDrives(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2.isFileSystemRoot(Unknown Source)
at sun.awt.shell.ShellFolder.isFileSystemRoot(Unknown Source)
at javax.swing.filechooser.FileSystemView.isFileSystemRoot(Unknown Source)
at javax.swing.filechooser.FileSystemView.getSystemDisplayName(Unknown Source)

 

[Owen Jacobson]

I've been using JDK 1.6.0_11 and occasionally, when
FileSystemView.getSystemDisplayName() is called, it just hangs. Below
is an excerpt of a thread-dump. Any ideas?

- Paul


"Thread-7" prio=6 tid=0x010e4c00 nid=0xdb0 waiting on condition
[0x29a8e000..0x29a8fb14]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x05d63708> (a java.util.concurrent.FutureTask$Sync)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)

[snip]

While the Javadocs for FileSystemView are mute on the subject, given
FileSystemView's close relationship with JFileChooser I'd be leery of
manipulating them on any thread but the Swing EDT.

[un-snip]

at java.util.concurrent.FutureTask.get(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown Source)

[snip again]

Interesting thing here. FutureTask.get is a blocking method which will
return whatever the task evaluates to, when the task completes. It
looks like, for one reason or another, the Windows integration
necessary to look up the file's display name executes some COM code in
a background task (presumably on its own thread, or in a JVM-owned
thread pool) which is never completing. A thread dump may tell you more
(send whatever the Windows analogue of SIGQUIT is to the JVM and it'll
dump thread stacks and lock info to stderr).

Wild-ass guess, but maybe you have a COM object installed on your
system that integrates with the Windows shell that's flakey? Explorer
extensions/integrations, for example.

-o

 

[Paul J. Lucas]

"Thread-7" prio=6 tid=0x010e4c00 nid=0xdb0 waiting on condition
[0x29a8e000..0x29a8fb14]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x05d63708> (a
java.util.concurrent.FutureTask$Sync)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)

[snip]

While the Javadocs for FileSystemView are mute on the subject, given
FileSystemView's close relationship with JFileChooser I'd be leery of
manipulating them on any thread but the Swing EDT.

[un-snip]

at java.util.concurrent.FutureTask.get(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2$ComInvoker.invoke(Unknown
Source)

[snip again]

Interesting thing here. FutureTask.get is a blocking method which will
return whatever the task evaluates to, when the task completes. It looks
like, for one reason or another, the Windows integration necessary to
look up the file's display name executes some COM code in a background
task (presumably on its own thread, or in a JVM-owned thread pool) which
is never completing. A thread dump may tell you more (send whatever the
Windows analogue of SIGQUIT is to the JVM and it'll dump thread stacks
and lock info to stderr).

Here's more from the thread dump.

- Paul

"Swing-Shell" daemon prio=6 tid=0x2b8e1c00 nid=0xa20 waiting on condition
[0x2c90f000..0x2c90fc94]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x05abe3c0> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(Unknown Source)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown
Source)
at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.getTask(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)

"Swing-Shell" daemon prio=6 tid=0x2b8e1000 nid=0x9f4 waiting on condition
[0x2c70f000..0x2c70fd14]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x05abef18> (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.getFileSystemPath(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.composePathForCsidl(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.<init>(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2.getDesktop(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.getDesktop(Unknown Source)
at sun.awt.shell.Win32ShellFolder2$1.call(Unknown Source)
at sun.awt.shell.Win32ShellFolder2$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)

 

[Albert]

Paul J. Lucas a écrit :

I've been using JDK 1.6.0_11 and occasionally, when
FileSystemView.getSystemDisplayName() is called, it just hangs. Below
is an excerpt of a thread-dump. Any ideas?

- Paul


"Thread-7" prio=6 tid=0x010e4c00 nid=0xdb0 waiting on condition
[0x29a8e000..0x29a8fb14]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x05d63708> (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.getFileSystemPath(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.composePathForCsidl(Unknown Source)
at sun.awt.shell.Win32ShellFolder2.<init>(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2.getDrives(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2.isFileSystemRoot(Unknown Source)
at sun.awt.shell.ShellFolder.isFileSystemRoot(Unknown Source)
at javax.swing.filechooser.FileSystemView.isFileSystemRoot(Unknown Source)
at javax.swing.filechooser.FileSystemView.getSystemDisplayName(Unknown
Source)

you should see:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6741890

 

[Roedy Green]

I've been using JDK 1.6.0_11 and occasionally, when
FileSystemView.getSystemDisplayName() is called, it just hangs. Below is an
excerpt of a thread-dump. Any ideas?

by any chance is the file in question in use by some other process,
e.g. a background indexer?
--
Roedy Green Canadian Mind Products
http://mindprod.com

One path leads to despair and utter hopelessness. The other,
to total extinction. Let us pray we have the wisdom to choose correctly.
~ Woody Allen .

 

[Paul J. Lucas]

by any chance is the file in question in use by some other process,
e.g. a background indexer?

I don't know for certain, but probably not. The same process does have another
thread that indexes files, however; but the odds are very low that a given file
would just so happen to be being indexed at the exact moment
getSystemDisplayName() is called.

- Paul

 

[Paul J. Lucas]

"Priority Low." Nice.

OTOH the Sun employ who has been assigned to this bug appears to be
asking for code to reproduce this issue. If you think you have some
code that you could trim down, Paul, and add it to the bug notes, it
might help Sun fix this.

The problem has never happened to me personally: it's happened to a tester of
ours. It only happens occasionally, presumably because certain things have to
be aligned just right for the deadlock to happen. But the bug description seems
to point right at why the deadlock happens. The Sun engineer should be able to
fix the deadlock just by inspection.

It's not clear to me why the Sun implementation needs a separate thread to
invoke COM stuff. It's my understanding that you can use COM functions on any
thread.

Anyway, I've just written by own trivial native Win32 COM code to get a file's
display name myself; so I'll use that rather than the Sun code.

- Paul