AppletViewer hangs under JDB in sun_awt_windows_WComponentPeer__dispose

Name: wm7046 Date: 06/27/97


The Problem

In 1.1.3B and 1.1.3E, AppletViewer hangs while under running under jdb. To reproduce the problem, debug AppletViewer remotely as follows:

In one MSDOS shell run the following command:


D:\>cd D:\jdk1.1.3E\demo\Clock
D:\jdk1.1.3E\demo\Clock>java_g -debug sun.tools.debug.EmptyApp
Agent password=4k66hp



In a second MSDOS shell, bring up jdb and run the application as follows:


D:\>cd D:\jkd1.1.3E\demo\Clock
D:\jdk1.1.3E\demo\Clock>jdb -password 5k5zze sun.applet.AppletViewer index.html
Initializing jdb...
0xf74988:class(sun.applet.AppletViewer)
> run
run sun.applet.AppletViewer index.html
running ...
main[1]



AppletViewer will now come up. Pull down the applet menu and open up various dialogs such as properties..., tag..., and info... Select various options and close the dialogs. Keep doing this until it hangs. It usually takes anywhere from 3 to 12 dialog openings before the hang will occur - but it is just about guarenteed to hang eventually.

Once the hang has occurred, select the MSDOS shell that has java_g running in it. Press . You should see a thread dump similar to the following:


Full thread dump:
    "Thread-3" (TID:0xf732e0, sys_thread_t:0x8a1960, Win32ID:0x112, state:CW) prio=4
        Clock2.run(Clock2.java:190)
        java.lang.Thread.run(Thread.java:474)
    "thread applet-Clock2.class" (TID:0xf7c7c0, sys_thread_t:0x899340, Win32ID:0xa3, state:CW) prio=4
        java.lang.Object.wait(Object.java:315)
        sun.applet.AppletPanel.getNextEvent(AppletPanel.java:220)
        sun.applet.AppletPanel.run(AppletPanel.java:244)
        java.lang.Thread.run(Thread.java:474)
    "Screen Updater" (TID:0xf7bc18, sys_thread_t:0x89d7a0, Win32ID:0x119, state:CW) prio=4
        java.lang.Object.wait(Object.java:315)
        sun.awt.ScreenUpdater.nextEntry(ScreenUpdater.java:78)
        sun.awt.ScreenUpdater.run(ScreenUpdater.java:98)
    "AWT-Windows" (TID:0xf79428, sys_thread_t:0x896640, Win32ID:0xdb, state:R) prio=5
        sun.awt.windows.WToolkit.run(WToolkit.java:108)
        java.lang.Thread.run(Thread.java:474)
    "AWT-EventQueue-0" (TID:0xf79380, sys_thread_t:0x8962d0, Win32ID:0xbe, state:CW) prio=5
        java.lang.StringBuffer.ensureCapacity(StringBuffer.java:181)
        java.lang.StringBuffer.append(StringBuffer.java:416)
        java.text.SimpleDateFormat.format(SimpleDateFormat.java:341)
        java.text.DateFormat.format(DateFormat.java:291)
        Clock2.paint(Clock2.java:123)
        Clock2.update(Clock2.java:197)
        java.awt.Component.dispatchEventImpl(Component.java:1414)
        java.awt.Container.dispatchEventImpl(Container.java:837)
        java.awt.Component.dispatchEvent(Component.java:1393)
        java.awt.EventDispatchThread.run(EventDispatchThread.java:63)
    "Breakpoint handler" (TID:0xf723d8, sys_thread_t:0x8821c0, Win32ID:0xf5, state:CW) prio=8
        java.lang.Object.wait(Object.java:315)
        sun.tools.debug.BreakpointQueue.nextEvent(BreakpointQueue.java:37)
        sun.tools.debug.BreakpointHandler.run(BreakpointHandler.java:221)
    "Step handler" (TID:0xf72460, sys_thread_t:0x882100, Win32ID:0xcb, state:CW) prio=10
        java.lang.Object.wait(Object.java:315)
        sun.tools.debug.StepRequest.get(StepHandler.java:908)
        sun.tools.debug.StepHandler.waitForRequest(StepHandler.java:140)
        sun.tools.debug.StepHandler.run(StepHandler.java:118)
    "Debugger agent" (TID:0xf65578, sys_thread_t:0x88a710, Win32ID:0xed, state:R) prio=10
        java.net.SocketInputStream.read(SocketInputStream.java:92)
        java.io.BufferedInputStream.fill(BufferedInputStream.java:135)
        java.io.BufferedInputStream.read(BufferedInputStream.java:162)
        java.io.FilterInputStream.read(FilterInputStream.java:81)
        sun.tools.debug.Agent.run(Agent.java:370)
        java.lang.Thread.run(Thread.java:474)
    "Finalizer thread" (TID:0xf600d0, sys_thread_t:0x874860, Win32ID:0xdc, state:R) prio=2
        sun.awt.windows.WComponentPeer.finalize(WComponentPeer.java:255)
    "main" (TID:0xf600a8, sys_thread_t:0x87d720, Win32ID:0xbb, state:CW) prio=5
Monitor Cache Dump:
     (0x8a1960):
        Waiters: 1
    java.lang.Class@F726F8/100F118:
        Waiters: 1
    java.lang.StringBuffer@F8F5B0/1077E80: owner "AWT-EventQueue-0" (0x8962d0, 2 entries)
    java.io.BufferedInputStream@F728E8/100F468: owner "Debugger agent" (0x88a710, 1 entry)
    sun.awt.windows.WLabelPeer@F8BF08/1039E60: owner "Finalizer thread" (0x874860, 1 entry)
    sun.awt.ScreenUpdater@F7BC18/1030098:
        Waiters: 1
    sun.tools.debug.BreakpointQueue@F72400/100E908:
        Waiters: 1
    sun.applet.AppletViewerPanel@F7CD50/1033DC0:
        Waiters: 1
Registered Monitor Dump:
    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:
    Java stack lock:
    Code rewrite lock:
    Heap lock:
    Has finalization queue lock:
    Finalize me queue lock:
        Waiters: 1
    Monitor cache expansion lock:
    Monitor registry:



I've done this probably a dozen times. The one thing I always see is a thread with a stack trace that is invoking sun.awt.windows.WComponentPeer.finalize(WComponentPeer.java:255). Sometimes it is the finalizer thread, more often it is some other thread such as AWT-EventQueue-0.

Our Diagnosis

If I attach a debugger to the java_g process using MS DeveloperStudio, I see the following stack trace on the finalizer thread:


NtWaitForSingleObject@12 + 11 bytes
WaitForSingleObjectEx@12 + 111 bytes
WaitForSingleObject@8 + 15 bytes
sun_awt_windows_WComponentPeer__dispose(Hsun_awt_windows_WComponentPeer * 0x00f8bf08) line 2001
Java_sun_awt_windows_WComponentPeer__0005fdispose_stub(stack_item * 0x01d0b348, execenv * 0x01eeff0c) line 290 + 11 bytes
invokeSynchronizedNativeMethod(Hjava_lang_Object * 0x00f8bf08, methodblock * 0x01dcfb3c, int 1, execenv * 0x01eeff0c) line 250 + 14 bytes
ExecuteJava(unsigned char * 0x01eefe3c, execenv * 0x01eeff0c) line 1702 + 22 bytes
do_execute_java_method_vararg(execenv * 0x01eeff0c, void * 0x00f8bf08, char * 0x01dceb90, char * 0x01dce5b0, methodblock * 0x01dd0438, int 0, char * 0x01eefee0, long * 0x00000000, int 0) line 595 + 13 bytes
do_execute_java_method(execenv * 0x01eeff0c, void * 0x00f8bf08, char * 0x00000000, char * 0x00000000, methodblock * 0x01dd0438, int 0) line 414 + 37 bytes
execute_finalizer(Hjava_lang_Object * 0x00f8bf08) line 64 + 23 bytes
finalizer_loop(Hjava_lang_Thread * 0x00f600d0) line 290 + 9 bytes
_start(sys_thread * 0x00874860) line 244 + 13 bytes
MSVCRT! 779f585d()



Code was added to the function sun_awt_windows_WComponentPeer__dispose in 1.1.3B to fix bug 4051487. The routine:


void
sun_awt_windows_WComponentPeer__dispose(Hsun_awt_windows_WComponentPeer* self)
{
    ASSERT(self != NULL && self->obj != 0);
    AwtComponent* p = (AwtComponent*)unhand(self)->pData;
    if (p == NULL) {
        return;
    }

    // Bug #4051487 (Borland show/dispose race condition)
    // Wait for all posted messages to be processed
    HANDLE hevt = CreateEvent(NULL, TRUE, FALSE, NULL);
    ASSERT(hevt);
    ::PostMessage(p->GetHWnd(), WM_AWT_QUEUE_SYNC, (WPARAM)hevt, 0);
    WaitForSingleObject(hevt, INFINITE);
    CloseHandle(hevt);

    delete p;

    ASSERT(PDATA(AwtComponent, self) == NULL);
}



Also, it is interesting that the Java method sun.awt.windows.WComponentPeer.finalize() has been modified in 1.1.2 to fix bug 4045616. The interesting thing about this fix, is that the symptoms sound very similar to what we are experiencing, except we are running under a debugger.


    protected void finalize() throws Throwable {

        _dispose(); // Fix for bug #4045616 -- Added '_' to dispose to avoid
                            // Oracle deadlock bug due to synchronous finalization in
                            // low memory situations.

        super.finalize();
    }




A couple possibly significant observations:


•When testing with 1.1.2FCS, instead of the hang - we see random Assertions when running appletviewer with java_g. It doesn't matter whether we are debugging or not.

•When testing with 1.1.3B or E we only see the hangs when running appletviewer under the debugger. Running appletviewer under java_g without the debugger has not hung - although its difficult to be absolutely certain that the problem can't occur - it may just be far less likely to occur.
======================================================================