I've discovered a race condition in AWT code in JDK 1.0.2. This shows
up as an occasional NullPointerException when running caffeinemark2
(http://www.webfayre.com/pendragon/cm2/index.html, right at the end of
the dialog test).

The following sequence of events (or something close to it, anyway)
leads to this error:

(1) Thread A disposes of a frame F. Eventually this ends up in
sun_awt_motif_MComponentPeer_pDispose() in
src/solaris/sun/awt_Component.c. That function tries to acquire the
AWT_LOCK , blocks, and control switches to Thread B.

(2) Thread B is running in awt_MToolkit_loop() in awt_MToolkit.c and
it has control of the AWT_LOCK. This code is processing events from
the X server. An "Expose" event for frame F is next, and the code
eventually gets to HandleExposeEvent() in canvas.c. This code checks
if the ComponentData structure is NULL and does nothing if that is the
case. However, frame F has not yet been disposed, so it continues
processing the Expose event. It calls callJavaExpose() in the same
file to call back into the interpreter. Before doing that, it releases
the AWT_LOCK (part of the JAVA_UPCALL macro).

(3) Thread B continues running in the
sun/awt/motif/MComponentPeer.handleExpose() method. It ends up back in
native code in sun_awt_motif_X11Graphics_createFromComponent() in
src/solaris/sun/awt_Graphics.c. That function tries to reacquire the
AWT_LOCK and control switches back to thread A.

(4) Thread A proceeds to acquire AWT_LOCK, dispose of frame F, and
release AWT_LOCK.

(5) Control resumes with Thread B. It acquires AWT_LOCK and checks
to see if the frame's "pData" field is 0. Because the frame
was just disposed it is 0, and thread B signals a NullPointerException
labeled "bar".