Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4061955

AppletViewer hangs under JDB in sun_awt_windows_WComponentPeer__dispose



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:
    • Verification:


      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...
      > run
      run sun.applet.AppletViewer index.html
      running ...

      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
          "thread applet-Clock2.class" (TID:0xf7c7c0, sys_thread_t:0x899340, Win32ID:0xa3, state:CW) prio=4
          "Screen Updater" (TID:0xf7bc18, sys_thread_t:0x89d7a0, Win32ID:0x119, state:CW) prio=4
          "AWT-Windows" (TID:0xf79428, sys_thread_t:0x896640, Win32ID:0xdb, state:R) prio=5
          "AWT-EventQueue-0" (TID:0xf79380, sys_thread_t:0x8962d0, Win32ID:0xbe, state:CW) prio=5
          "Breakpoint handler" (TID:0xf723d8, sys_thread_t:0x8821c0, Win32ID:0xf5, state:CW) prio=8
          "Step handler" (TID:0xf72460, sys_thread_t:0x882100, Win32ID:0xcb, state:CW) prio=10
          "Debugger agent" (TID:0xf65578, sys_thread_t:0x88a710, Win32ID:0xed, state:R) prio=10
          "Finalizer thread" (TID:0xf600d0, sys_thread_t:0x874860, Win32ID:0xdc, state:R) prio=2
          "main" (TID:0xf600a8, sys_thread_t:0x87d720, Win32ID:0xbb, state:CW) prio=5
      Monitor Cache Dump:
              Waiters: 1
              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)
              Waiters: 1
              Waiters: 1
              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:

      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) {

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

          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.


      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.


          Issue Links



              duke J. Duke (Inactive)
              mmma Marvin Ma (Inactive)
              0 Vote for this issue
              0 Start watching this issue