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.