From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 967 invoked by alias); 7 Aug 2004 00:43:53 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 942 invoked by uid 48); 7 Aug 2004 00:43:51 -0000 Date: Sat, 07 Aug 2004 00:43:00 -0000 Message-ID: <20040807004351.941.qmail@sourceware.org> From: "Hans dot Boehm at hp dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20040721214713.16662.mckinlay@redhat.com> References: <20040721214713.16662.mckinlay@redhat.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/16662] IllegalMonitorStateException in EventQueue.getNextEvent(): possible hash synchronization bug? X-Bugzilla-Reason: CC X-SW-Source: 2004-q3/txt/msg00192.txt.bz2 List-Id: ------- 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