From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16039 invoked by alias); 5 Aug 2004 00:56:50 -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 16016 invoked by uid 48); 5 Aug 2004 00:56:48 -0000 Date: Thu, 05 Aug 2004 00:56:00 -0000 Message-ID: <20040805005648.16015.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/msg00176.txt.bz2 List-Id: ------- Additional Comments From Hans dot Boehm at hp dot com 2004-08-05 00:56 ------- I'm looking at this, and trying to remember the intricacies of this code. It appears that the faulting thread successfully acquired the heavyweight lock on an object (presumably because the lightweight entry was used for another object) and then another thread later acquired the lightweight lock on the same object. This should of course be impossible. Looking at the code, I noticed that _Jv_ObjectCheckMonitor appears broken. If the address in the lightweight lock is zero, we may still hold a heavyweight lock on the object. This can happen since the lightweight lock slots are shared between objects. Thus it may have been in use when we first tried to acquire the lock. But I don't know what relies on _Jv_ObjectCheckMonitor. I would guess it has nothing to do with this problem. -- What |Removed |Added ---------------------------------------------------------------------------- CC| |Hans dot Boehm at hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662