Name: chT40241 Date: 10/22/97


This problem can be observed debugging the Microsoft J++ sample applet under under HotJava. This situation can produce a number of different previously reported problems, so here is the description from one of them:

 >
 > D:\javabugs\sample>jdb "-Dhotjava.home=D:\Hotjava"
 > "-Dapplet.allow.namespace=true" sun.hotjava.Main
 > file:D:\javabugs\sample\sample.html
 > Initializing jdb...
 > 0xf73128:class(sun.hotjava.Main)
 > > stop in sample.init
 > Breakpoint set in sample.init
 > > run
 > run sun.hotjava.Main file:D:\javabugs\sample\sample.html
 > running ...
 > main[1] .Starting HotJava.
 > .Initializing globals.
 > .Creating frame.
 > .Loading: C:\\.hotjava\urlpool.
 > .Loaded DTD html32 in 687ms.
 >
 > Breakpoint hit: sample.init (sample:107)
 > thread applet-sample.class[1] list
 > 103 // CreateControls() method from within this method.
 > Remove the following
 > 104 // call to resize() before adding the call to
 > CreateControls();
 > 105 // CreateControls() does its own resizing.
 > 106
 > //----------------------------------------------------------------------
 > 107 => resize(320, 240);
 > 108
 > 109 // TODO: Place additional initialization code
 > here
 > 110 }
 > 111
 > thread applet-sample.class[1] next
 > thread applet-sample.class[1]
 
The next command above never completes, because the StepHandler
thread is in a deadly embrace with an AWT thread ("Image Animator").
The ImageAnimator thread owns the cache expansion lock, and is waiting for the thread queue lock, while the StepHandler thread holds the queue lock and is waiting for the cache expansion lock.
 
The problem was caused by a change to monitor_cache.c, which is
described in the comments as a fix for green threads. The fix causes
the thread queue lock to be obtained while holding the cache
expansion lock. Unfortunately, the lock_for_debugger code in gc.c
assumes that the relation between the two locks is in the other order,
and locks the thread queue before taking the cache expansion lock.
These two pieces of code need to take the locks in a consistent order.

This problem seems to occur often when debugging this applet under HotJava; perhaps 20 % of the time.

======================================================================