From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15934 invoked by alias); 25 Nov 2004 01:50:33 -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 15859 invoked by uid 48); 25 Nov 2004 01:50:32 -0000 Date: Thu, 25 Nov 2004 01:50:00 -0000 Message-ID: <20041125015032.15858.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: 2004-q4/txt/msg00401.txt.bz2 List-Id: ------- Additional Comments From Hans dot Boehm at hp dot com 2004-11-25 01:50 ------- After finally finding time to look at the code, it appears that my earlier guesses were correct. ::java::lang::ref::Reference::create in natReference.cc calls _Jv_RegisterFinalizer(referent ...), where referent is an arbitrary object, which may already have a finalizer. This is bad news, since the original finalizer will be dropped. The original finalizer may be a Java finalizer, or it may be one that was registered by the hash synchronization code to clean up a heavy lock entry for the object. In either case we lose. (The hash synchronization code is careful to not lose the original finalizer.) In both cases I think, we are likely to mostly introduce leaks, and crash only occasionally. So this may explain some other misbehavior. The fix may require some thought. At a minimum, we need to export more GC functionality, so that the Reference implementation can retrieve the old finalizer. (The hash synchronization code currently cheats and goes directly to the GC interface, which should also be fixed.) I think that so long as Reference gets the ordering right, and doesn't assume that all finalizers are Java finalizers, the hash synchronization code should work. It needs to drop the heavy lock before the object is deallocated, and while the lock is not held. I don't think the timing otherwise matters. If the object is resurrected 17 times, we can drop the heavy lock at any of those points, recreating it if necessary. This really needs to be fixed to make any use of References reliable. -- What |Removed |Added ---------------------------------------------------------------------------- CC| |tromey at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266