JDK-4225375 : JFileChooser hangs when jaz drive exists
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.1.7
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-03-30
  • Updated: 1999-03-30
  • Resolved: 1999-03-30
Description

Name: vi73552			Date: 03/30/99


This program hangs every time. The system
has a Jaz drive as the E: drive. This is for Swing-1.1.1-beta1

import java.io.File;
import javax.swing.JFileChooser;
import javax.swing.filechooser.FileFilter;

class TstFC
{
    public static void main(String[] args)
    {
    	String lastPath = null;
		JFileChooser chooser = new JFileChooser(lastPath);
		FileFilter filter = new FileFilter()
		{
			public boolean accept(File f)
			{
				boolean ok = f.isDirectory();
				if( ok == false )
				{
					String name = f.getName();
					ok = name.endsWith(".jar");
					if( ok == false )
						ok = name.endsWith(".jar");
				}
				return ok;
			}
			public String getDescription()
			{
				return "Classpath elements(dir,*.zip,*.jar)";
			}
		};
		chooser.setFileFilter(filter);
		int returnVal = chooser.showOpenDialog(null);
		if( returnVal == JFileChooser.APPROVE_OPTION )
		{
			File file = chooser.getSelectedFile();
			System.out.println("Selected "+file);
		}
	}
}

D:\VisualCafe\Projects\SwingTsts>java TstFC

Full thread dump:
    "Screen Updater" (TID:0xca0ae0, sys_thread_t:0x90d690, Win32ID:0x132, state:
CW) prio=4
        java.lang.Object.wait(Object.java:307)
        sun.awt.ScreenUpdater.nextEntry(Compiled Code)
        sun.awt.ScreenUpdater.run(Compiled Code)
    "AWT-Windows" (TID:0xc85458, sys_thread_t:0x8b48c0, Win32ID:0x20b, state:R)
prio=5
        sun.awt.windows.WToolkit.run(WToolkit.java:98)
        java.lang.Thread.run(Thread.java:466)
    "AWT-EventQueue-0" (TID:0xc85530, sys_thread_t:0x8b4b60, Win32ID:0x335, stat
e:CW) prio=5
        java.lang.Object.wait(Object.java:307)
        java.awt.EventQueue.getNextEvent(Compiled Code)
        java.awt.EventDispatchThread.run(EventDispatchThread.java:67)
    "Finalizer thread" (TID:0xc80088, sys_thread_t:0x8997f0, Win32ID:0x5d, state
:CW) prio=2
    "main" (TID:0xc800b0, sys_thread_t:0x898a40, Win32ID:0x2cf, state:CW) prio=5

        java.lang.Object.wait(Object.java:307)
        sun.awt.windows.WDialogPeer$ModalLock.waitModal(WDialogPeer.java:24)
        sun.awt.windows.WDialogPeer.show(WDialogPeer.java:61)
        java.awt.Dialog.show(Dialog.java:219)
        javax.swing.JFileChooser.showDialog(JFileChooser.java:509)
        javax.swing.JFileChooser.showOpenDialog(JFileChooser.java:449)
        TstFC.main(TstFC.java:32)
Monitor Cache Dump:
    sun.awt.ScreenUpdater@CA0AE0/D3F3D8: <unowned>
        Waiters: 1
    java.awt.EventQueue@C852C8/CD8FD8: <unowned>
        Waiters: 1
    sun.awt.windows.WDialogPeer$ModalLock@C9DDD0/D48E20: <unowned>
        Waiters: 1
Registered Monitor Dump:
    SymcJIT Method Monitor: <unowned>
    SymcJIT Method Monitor: <unowned>
    SymcJIT Method Monitor: <unowned>
    SymcJIT Method List Monitor: <unowned>
    SymcJIT Fixups Allocation: <unowned>
    SymcJIT Code Allocation: <unowned>
    SymcJIT Data Allocation: <unowned>
    Thread queue lock: <unowned>
    Name and type hash table lock: <unowned>
    String intern lock: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class loading lock: <unowned>
    Java stack lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Has finalization queue lock: <unowned>
    Finalize me queue lock: <unowned>
        Waiters: 1
    Monitor registry: <unowned>
^C
D:\VisualCafe\Projects\SwingTsts>java -version
java version "1.1.7B"
(Review ID: 56268) 
======================================================================

Comments
PUBLIC COMMENTS from Scott M Stark (user): After further investigation, there were actually two other issues causing the problem. 1. There was a stale drive mapping to a computer that was not up. This was causing the scan of the C-Z drives to hang on the stale drive until it timed out. 2. Because it was taking so long for the dialog to display, I had selected the task manager and the explorer to try to see what was going on. When the stale drive did timeout, the JFileChooser dialog was displayed behind all other windows rather than coming to the front and so I did not see it the first few times I ran the test case.
10-06-2004

EVALUATION from Scott M Stark (user): After further investigation, there were actually two other issues causing the problem. 1. There was a stale drive mapping to a computer that was not up. This was causing the scan of the C-Z drives to hang on the stale drive until it timed out. 2. Because it was taking so long for the dialog to display, I had selected the task manager and the explorer to try to see what was going on. When the stale drive did timeout, the JFileChooser dialog was displayed behind all other windows rather than coming to the front and so I did not see it the first few times I ran the test case. Vassili.Igouchkine@Russia 1999-03-30
30-03-1999