From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27922 invoked by alias); 10 Aug 2004 00:44:34 -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 27906 invoked by uid 48); 10 Aug 2004 00:44:34 -0000 Date: Tue, 10 Aug 2004 00:44:00 -0000 Message-ID: <20040810004434.27903.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/msg00205.txt.bz2 List-Id: ------- Additional Comments From Hans dot Boehm at hp dot com 2004-08-10 00:44 ------- One other small piece of data: In the failing runs I've seen, only a single heavy lock (for the user lock which eventually causes the problem) is allocated at the beginning of the run. Thus the chain of heavy locks is indeed completely static, as should be expected. I'm attempting to reproduce the failure with some circular buffer logging code, but even without that, it currently takes me hours to reproduce the problem. Based on further inspection, there does seem to be another problem with Object.wait() only notifying a single thread if it inflates the lock. It should notify all waiters. But that seems to be an extremely unlikely scenario, and should only result in performance or possibly deadlock issues, and only if there are more than two threads involved. I will include it in the patch I'm accumulating. Hans -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662