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

Solaris: Dialog disposal (possibly all peered Component disposal) causes crash


    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.1.7
    • Fix Version/s: None
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:


      To reproduce this bug, run the regression test


      (The test has also been attached to this bug for convenience.)

      Click the "test" button to show the modal dialog, and then click the "dismiss-
      with-dispose" button. You will need to repeat this about 50 times to see the
      following crash:

      Xt error
      SIGSEGV 11* segmentation violation
          si_signo [11]: SIGSEGV 11* segmentation violation
          si_errno [0]: Error 0
          si_code [1]: SEGV_MAPERR [addr: 0x154]

              stackbase=EDDF2000, stackpointer=EDDF0FD0

      Full thread dump:
          "Screen Updater" (TID:0xee314680, sys_thread_t:0xeddc1db8, state:CW) prio=4
          "AWT-Motif" (TID:0xee312640, sys_thread_t:0xeddf1db8, state:R) prio=5: pending=java.lang.NullPointerException *current thread*
          "AWT-Input" (TID:0xee312660, sys_thread_t:0xedfc1db8, state:CW) prio=5
          "AWT-EventQueue-0" (TID:0xee312678, sys_thread_t:0xedff1db8, state:CW) prio=5
          "thread applet-HideDialogTest" (TID:0xee311b00, sys_thread_t:0xef2c1db8, state:CW) prio=4
          "Finalizer thread" (TID:0xee300210, sys_thread_t:0xef2f1db8, state:CW) prio=1
          "Async Garbage Collector" (TID:0xee300258, sys_thread_t:0xef3f1db8, state:R) prio=1
          "Idle thread" (TID:0xee3002a0, sys_thread_t:0xef4c1db8, state:R) prio=0
          "Clock" (TID:0xee300088, sys_thread_t:0xef4f1db8, state:CW) prio=12
          "main" (TID:0xee3000b0, sys_thread_t:0x45f20, state:CW) prio=5
      Monitor Cache Dump:
          sun.awt.ScreenUpdater@EE314680/EE381030: <unowned>
              Waiting to be notified:
                  "Screen Updater" (0xeddc1db8)
          sun.awt.motif.MToolkit@EE312440/EE379230: owner "AWT-Motif" (0xeddf1db8, 1 entry)
              Waiting to be notified:
                  "AWT-Input" (0xedfc1db8)
          java.awt.EventQueue@EE312410/EE379680: <unowned>
              Waiting to be notified:
                  "AWT-EventQueue-0" (0xedff1db8)
          sun.applet.AppletViewerPanel@EE3117E0/EE3764A8: <unowned>
              Waiting to be notified:
                  "thread applet-HideDialogTest" (0xef2c1db8)
          <unknown key> (0xef3f1db8): owner "Async Garbage Collector" (0xef3f1db8, 1 entry)
      Registered Monitor Dump:
          Thread queue lock: <unowned>
              Waiting to be notified:
                  "main" (0x45f20)
          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>
              Waiting to be notified:
                  "Finalizer thread" (0xef2f1db8)
          Dynamic loading lock: <unowned>
          Monitor IO lock: <unowned>
          Child death monitor: <unowned>
          Event monitor: <unowned>
          I/O monitor: <unowned>
          Alarm monitor: <unowned>
              Waiting to be notified:
                  "Clock" (0xef4f1db8)
          Sbrk lock: <unowned>
          Monitor registry: owner "AWT-Motif" (0xeddf1db8, 1 entry)
      Thread Alarm Q:
      Abort (core dumped)

      The crash seems to happen only with green threads. A core file has been
      attached. Analyzing the core in dbx, we can see that the XEvent structure
      has a NIL display. This probably causes the crash in _XtSortPerDisplayList.

      This bug may have been introduced by the XPutBack change to awt_Component.c.
      We know that this change is wrong for at least one reason: it can cause
      out-of-order execution of XEvents. This problem has been fixed in 1.2, but
      not in 1.1.7. See the current 1.2 codebase for the corrected implementation.




            • Assignee:
              mmartaksunw Michael Martak (Inactive)
              dmendenhsunw David Mendenhall (Inactive)
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: