[Bug libgcj/16662] IllegalMonitorStateException in EventQueue.getNextEvent(): possible hash synchronization bug?

["Hans dot Boehm at hp dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From Hans dot Boehm at hp dot com  2004-08-07 00:43 -------
I can also reproduce the problem on a dual PII/266 machine, though it seems to 
often take a while.

I have no real answer, but here are some more observations, mostly as notes to 
myself:

1) The failure occurs in the popping thread, i.e. the thread that executes 
Object.wait().

2) When the lock is first printed, the lightweight lock appears to be held by 
the pushing (notifying) thread, partially confirming prior suspicion that wait
() somehow confuses the state of the lock, allowing two threads to 
simultaneously acquire it.  (Presumably if this were reproducible without wait
() we would have seen it much earlier.)

3) When the lock is first printed, the lightweight lock appears held by  the 
other thread, but the flag indicating that there are also heavyweight locks 
hashing to the same location is set.  It seems likely that the heavyweight lock 
for this location is allocated and held.

4) When the lock is printed a second time, the lightweight lock has 
consistently been released.  The heavyweight lock appears to still be held 
twice.  (HEAVY bit set, heavy_count = 2, and no other objects have locks on 
this hash chain, there can't be any waiters, which would be included in the 
count.)

5) Changing the locking code such that maybe_remove_all_heavy() is never 
executed affects nothing.  (It shouldn't, since the lock chain should never 
grow in this example.  But this eliminates that code from suspicion.) 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662