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

Race condition in menuitem deletion causes trap

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P1
    • Resolution: Fixed
    • Affects Version/s: 1.1.2
    • Fix Version/s: 1.1.5
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      1.1.5
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Description

      Dispose was called on a MenuItem at the same time that the MenuItem was
      handling a WM_DRAWITEM message causing a trap when the class AwtMenu is freed.
      Synchronization needs to be added to ensure that this cannot occur.


      ingrid.yao@Eng 1997-08-14

      More info provided by Oracle:
      =================================
      The trap occurs when dispose is called on a MenuItem at the same
      time that the menu is being drawn.

      The Window thread receives a WM_DRAWITEM message and starts drawing
      the menu by calling the DrawItem methods in awt_Menu.cpp,
      awt_MenuItem.cpp and awt_MenuBar.cpp.

      At the same time a MenuItem is removed from the menu by another thread,
      causing the peer code to delete the c++ object. If the memory
      gets reallocated (and hence cleared), while the window thread is
      accessing the deleted class, the window thread traps, trying to use 0
      as a pointer.

      I haven't had any luck reproducing this in a testcase, because with
      a small applet the freed c++ object doesn't get reallocated immediately
      and so the fact that the Window Thread is pointing to freed memory
      doesn't cause a problem.

      You could try to reproduce it by having multiple threads adding and
      removing MenuItems, while you open and close the menu, causing the
      menu to be painted repeatedly. Perhaps you could reduce the heap
      size to simulate a larger applet.

      Frame.setMenu() causes some similar problems because references to
      the deleted c++ object are kept in a couple of places.

      The fix I suggested was basically the same fix that has been put into
      the Component dispose code, which is to wait until the windows thread
      has finished processing messages before deleting the c++ object.
      This solution is less than ideal, because a message may arrive
      after the wait and before the delete. I figured that if this fix was
      regarded, by Javasoft, as good enough for Components it would be
      regarded as good enough for MenuItems:)

      A better fix for both Component disposal and MenuItem disposal, would be:

      - In _dispose, post a message WM_AWT_DESTROY to the Window Thread and
        mark the c++ object as invalid.
      - In response to WM_AWT_DESTROY, call DestroyWindow on the c++ object's window
      - In WM_DESTROY processing, delete the c++ object; this is guaranteed to be the
        last message dispatched to a window.
      - check if the c++ object is marked as invalid before referencing it.

      The c++ object has to be marked in some way because it contains a reference
      to the Java object, which is invisible to the garbage collector. After
      the _dispose call there are no other references to the Java object, so it
      could be freed.

        Attachments

          Activity

            People

            Assignee:
            duke J. Duke (Inactive)
            Reporter:
            sgoodsunw Sheri Good (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: