Name: wm7046 Date: 08/14/97


The Problem

When running jdb (or some other debugger) under Windows NT, a deadlock may occur when setting a breakpoint, or when performing any other activity which may cause class loading to take place. We found that when we attempt to debug the Microsoft sample application under HotJava, this problem occurs between 10 and 15 % of the time. To reproduce the problem, use the same steps as for problem 4068874, to wit:

Here are the steps that produced the problem:


D:\javabugs\sample>jdb "-Dhotjava.home=D:\Hotjava" "-Dapplet.allow.namespace=true" sun.hotjava.Main file:D:\javabugs\sample\sample.html
Initializing jdb...
0xf73128:class(sun.hotjava.Main)
> stop in sample.init
Breakpoint set in sample.init
> run
run sun.hotjava.Main file:D:\javabugs\sample\sample.html
running ...
main[1] [Starting HotJava]
[Initializing globals]
[Creating frame]
[Loading: C:\\.hotjava\urlpool]
[Loaded DTD html32 in 687ms]
Breakpoint hit: sample.init (sample:107)
thread applet-sample.class[1] list
103 // CreateControls() method from within this method.
Remove the following
104 // call to resize() before adding the call to
CreateControls();
105 // CreateControls() does its own resizing.
106
//----------------------------------------------------------------------
107 => resize(320, 240);
108
109 // TODO: Place additional initialization code
here
110 }
111
thread applet-sample.class[1] next
thread applet-sample.class[1]
Breakpoint hit: sample.init (sample:99)
thread applet-sample.class[1] stop in sample.displayImage



At this point it was locked up.

Our Analysis

Use of ctrl-break at this point produces a thread dump similar to the following:


Full thread dump:
    "thread applet-sample.class" (TID:0xf4eda0, sys_thread_t:0x8bd1e0,Win32ID:0x116, state:S) prio=4
        sample.init(sample.java:99)
        sun.applet.AppletPanel.run(AppletPanel.java:287)
        sun.hotjava.tags.TagAppletPanel.run(TagAppletPanel.java:202)
        java.lang.Thread.run(Thread.java:474)
    "DocParser" (TID:0xf8feb0, sys_thread_t:0x8b52b0, Win32ID:0x10f,state:S) prio=4
        java.io.FileOutputStream.(FileOutputStream.java:67)
        sun.hotjava.misc.EditorProperties.save(EditorProperties.java:102)
        sun.hotjava.misc.Globals.setCharset(Globals.java:341)
        sun.hotjava.doc.DocParser.done(DocParser.java:713)
        sun.hotjava.doc.DocParser.run(DocParser.java:548)
        java.lang.Thread.run(Thread.java:474)
    "Screen Updater" (TID:0xf83e48, sys_thread_t:0x89a240, Win32ID:0xa2,state:S) prio=4
        sun.awt.ScreenUpdater.nextEntry(ScreenUpdater.java:87)
        sun.awt.ScreenUpdater.run(ScreenUpdater.java:98)
    "Image Animator" (TID:0xf7f5c0, sys_thread_t:0x897e40,Win32ID:0x114, state:S) prio=2
        sun.awt.image.ImageDecoder.nextConsumer(ImageDecoder.java:58)
        sun.awt.image.ImageDecoder.setPixels(ImageDecoder.java:122)
        sun.awt.image.GifImageDecoder.sendPixels(GifImageDecoder.java:411)
        sun.awt.image.GifImageDecoder.readImage(GifImageDecoder.java:552)
        sun.awt.image.GifImageDecoder.produceImage(GifImageDecoder.java:223)
        sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:265)
        sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:151)
        sun.awt.image.ImageFetcher.run(ImageFetcher.java:127)
    "AWT-Windows" (TID:0xf75d58, sys_thread_t:0x895110, Win32ID:0xf4,state:S) prio=5
        sun.awt.windows.WToolkit.run(WToolkit.java:108)
        java.lang.Thread.run(Thread.java:474)
    "AWT-EventQueue-0" (TID:0xf760e8, sys_thread_t:0x895f40,Win32ID:0xfd, state:S) prio=5
        java.lang.Object.wait(Object.java:315)
        java.awt.EventQueue.getNextEvent(EventQueue.java:119)
        java.awt.EventDispatchThread.run(EventDispatchThread.java:55)
    "Alloc State Notifier" (TID:0xf7d7b8, sys_thread_t:0x88fa00,Win32ID:0x77, state:S) prio=8
        java.lang.Object.wait(Object.java:315)
        sun.misc.VMNotifierThread.run(VM.java:154)
    "Red Alloc State Notifier" (TID:0xf7d898, sys_thread_t:0x88f920,Win32ID:0x65, state:S) prio=10
        java.lang.Object.wait(Object.java:315)
        sun.misc.VMNotifierThread.run(VM.java:154)
    "Request Processor" (TID:0xf7e028, sys_thread_t:0x890c70,Win32ID:0x45, state:S) prio=6
        sun.misc.Queue.dequeue(Queue.java:90)
        sun.misc.Queue.dequeue(Queue.java:74)
        sun.misc.RequestProcessor.run(RequestProcessor.java:56)
        java.lang.Thread.run(Thread.java:474)
    "Breakpoint handler" (TID:0xf70b68, sys_thread_t:0x873890,Win32ID:0x9b, state:CW) prio=8
        java.lang.Object.wait(Object.java:315)
        sun.tools.debug.BreakpointQueue.nextEvent(BreakpointQueue.java:63)
        sun.tools.debug.BreakpointHandler.run(BreakpointHandler.java:203)
    "Step handler" (TID:0xf70bf0, sys_thread_t:0x8737d0, Win32ID:0x64,state:CW) prio=10
        java.lang.Object.wait(Object.java:315)
        sun.tools.debug.StepRequest.get(StepHandler.java:946)
        sun.tools.debug.StepHandler.waitForRequest(StepHandler.java:173)
        sun.tools.debug.StepHandler.run(StepHandler.java:150)
    "Debugger agent" (TID:0xf65620, sys_thread_t:0x87ccb0,Win32ID:0x104, state:R) prio=10
        sun.tools.debug.Agent.handle(Agent.java:666)
        sun.tools.debug.Agent.run(Agent.java:372)
        java.lang.Thread.run(Thread.java:474)
    "Finalizer thread" (TID:0xf600d0, sys_thread_t:0x8747c0,Win32ID:0x111, state:CW) prio=2
    "main" (TID:0xf600a8, sys_thread_t:0x87d720, Win32ID:0x76, state:S) prio=5
Monitor Cache Dump:
    sun.hotjava.doc.DocParser@F90078/1098FA8: owner "DocParser" (0x8b52b0, 1 entry)
    sun.awt.ScreenUpdater@F83E48/1056618:
        Waiters: 1
    sun.misc.Queue@F7DE28/1042A78:
        Waiters: 1
    sun.misc.VMNotifierThread@F7D7B8/1042F50:
        Waiters: 1
    sun.misc.VMNotifierThread@F7D898/1042E98:
        Waiters: 1
    java.awt.EventQueue@F76250/1044088:
        Waiters: 1
    java.lang.Class@F70EA8/1010E08:
        Waiters: 1
    sun.tools.debug.BreakpointQueue@F70B90/100FC80:
        Waiters: 2
        Tickets: 1
    sun.tools.debug.Agent@F653C0/FB4260: owner "Debugger agent" (0x87ccb0, 1 entry)
Registered Monitor Dump:
    Verifier lock:
    Thread queue lock:
        Waiters: 1
    Name and type hash table lock:
    String intern lock:
    JNI pinning lock:
    JNI global reference lock:
    BinClass lock:
    Class loading lock: owner "Debugger agent" (0x87ccb0, 1 entry)
    Java stack lock:
    Code rewrite lock:
    Heap lock:
    Has finalization queue lock:
    Finalize me queue lock:
        Waiters: 1
    Monitor cache expansion lock:
    Monitor registry:



The distinctive thing about this thread dump is the status of the DocParser thread, which is executing:


        java.io.FileOutputStream.(FileOutputStream.java:67)



Checking for this situation allows this problem to be distinguished from 4068874 and 4068870, which can also occur after this sequence of commands.

The problem occurs because it appears the Windows NT open function performs some kind of thread synchronization which prevents more than one thread from doing an open at the same time. (We have not yet been able to determine if this represents correct Windows behavior or if it represents a bug of some kind.) In this particular case, the DocParser thread, in the constructor for FileOutputStream, has issued an open() call. At this point, the thread was suspended by the debugger. When the "stop" command was issued to the debugger, the debugger Agent attempted to load the class in which the breakpoint was to be set. This required opening a classes.zip file, and the call to open() to perform this hung. We have verified that unsuspending the DocParser thread resolves the deadlock, that is, the problem would not have occurred without the debugger's unlucky suspension of the DocParser thread.

It would appear that one way of solving this problem would be to protect calls to open() under Windows with a lock. We are working on implementing and testing such a solution.

======================================================================