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

Win95/NT invalid page fault crash

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b01
    • CPU:
      x86
    • OS:
      windows_95, windows_nt
    • Verification:
      Verified

      Backports

        Description



        STEPS TO REPRODUCE:
        =======================
        This happens on Win95 with 256 colors for sure and it
        happens some percentage of the time (about 20-25% of the
        time so you need to run it at least 20 times to see the
        effect).

        TEST CASE: (below is code for file PaletteTest.java)
        ======================================
        package borland.test.mike;

        import java.awt.*;

        public class PaletteTest
        {
          public int getJavaPalette() {
            try {
              //!CQ would like to just use the AddinFrame, but it is not
        yet created. Neet to reorganize when we create it
              java.awt.Frame f = new java.awt.Frame();
              f.setBounds(-100,-100,0,0);
              f.setVisible(true); // make sure HWND exists
              sun.awt.DrawingSurface surface =
        (sun.awt.DrawingSurface)f.getPeer();
              sun.awt.windows.WDrawingSurfaceInfo info =
        (sun.awt.windows.WDrawingSurfaceInfo)surface.getDrawingSurfaceInfo();
              int palette = info.getHPalette();
              f.dispose();
              return palette;
            }
            catch (Exception e) {
              e.printStackTrace();
              return 0;
            }
          }


          public static void main(String[] args) {
            PaletteTest pt = new PaletteTest();

            for (int i = 0; i < 100; i++) {
              Byte[] strings = new Byte[100000];
              int val = pt.getJavaPalette();
              System.out.println("getJavaPalette returns " + val);
            }
            System.exit(0);
          }
        }



        ingrid.yao@Eng 1997-11-11

        Oracle reported the race condition still exists:

        The __dispose method (in src\win32\sun\windows\awt_Component.cpp) is called
        from a Java thread (it's part ComponentPeer) at the same time as the window
        thread is handling a message to the same peer object. The _dispose method
        calls delete on the C++ object while it is being used by the window thread,
        causing the window thread to trap!
         
        Javasoft's fix:
         
        Post a message to the window thread and wait for an event semaphore before
        deleting the C++ object. The message handler posts the event semaphore,
        allowing the _dispose call to continue.
         
        The idea is to flush the message queue before deleting the C++ object, thus
        avoiding the race condition. Unfortunately there is still a race condition
        if a message is posted and processing starts between posting the event
        semaphore and deleting the C++ object and it doesn't flush timer messages,
        which are delivered after all other messages (the fix is dependant on messages
        being delivered in the order that they are posted, which is not true on
        Windows).

        Oracle's fix:
         
        Put the Java thread to sleep after posting the event semaphore, so the other
        messages in the message queue have a chance of being processed before the
        C++
        object is deleted.
         

         

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                dmendenhsunw David Mendenhall (Inactive)
                Reporter:
                rschiavisunw Richard Schiavi (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: