From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32321 invoked by alias); 9 Jun 2005 05:11:16 -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 31695 invoked by uid 48); 9 Jun 2005 05:10:42 -0000 Date: Thu, 09 Jun 2005 05:11:00 -0000 Message-ID: <20050609051042.31683.qmail@sourceware.org> From: "Hans dot Boehm at hp dot com" To: java-prs@gcc.gnu.org In-Reply-To: <20041101172052.18266.ovidr@users.sourceforge.net> References: <20041101172052.18266.ovidr@users.sourceforge.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner () X-Bugzilla-Reason: CC X-SW-Source: 2005-q2/txt/msg00722.txt.bz2 List-Id: ------- Additional Comments From Hans dot Boehm at hp dot com 2005-06-09 05:10 ------- Unfortunately, I haven't had time to pursue this. I think that in order to get this to fail, you want lots of weak references to objects which are also sobject to lock contention or wait/notify calls. I don't think we currently have a good test case. My impression is that natReference.cc already keeps a fairly elaborate data structure to which you should be able to add the prior finalization info, so that it can be invoked at the right point by the existing finalizer there. In general, the GC's data structures don't queue multiple finalizers. You need to register a new finalizer that knows it has to reregister the old one when it's done. The information that there was another finalizer needs to be kept off to the side somewhere in a separate table, or as part of the "client data" registered with the finalizer. The locking code also has to deal with opaque objects, but it again has its own hash table off to the side. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266