public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Hans dot Boehm at hp dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner () Date: Mon, 01 Nov 2004 20:44:00 -0000 [thread overview] Message-ID: <20041101204421.30244.qmail@sourceware.org> (raw) In-Reply-To: <20041101172052.18266.ovidr@users.sourceforge.net> ------- Additional Comments From Hans dot Boehm at hp dot com 2004-11-01 20:44 ------- This would be a lot easier if libgcj had been built with something like -O2 -g. Based on approximate manual matching of the object code to finalize.s, I think this is failing around line 452 of finalize.c on the line new_fo -> fo_object_size = hhdr -> hb_sz; It appears that hhdr is in %edx and is 1. This can occur if the first argument to GC_register_finalizer_inner is a pointer to somewhere in the second page of a large object. It should of course be a base pointer to an object, so this should be impossible. I think the GC_register_finalizer_no_order call must be coming from maybe_remove_all_heavy(), which called remove_all_heavy, which was presumably inlined into _Jv_MonitorExit(). I see no other path to GC_register_finalizer_no_order(). That makes it appear that an object whose heavy-weight lock we are about to remove has previously been garbage collected. That should be impossible since we previously registered our own finalizer for the object in question, and that acquires the lock bit in the lock hash table entry, as does remove_all_heavy. Thus the finalizer should have previously been run to completion, and all traces of the heavy lock should have been previously removed. Are there places we add a finalizer to an existing object without checking for prior finalizers? That might explain the problem. We really need some more evidence to confirm this chain of reasoning. A -g stack trace, and the values of the finalization proc and data (and the object the data pointer points to, if any) that are being passed to GC_register_finalizer_inner might help. So would GC_find_header (object_being_registered_address). Assuming that's one, as expected, then *GC_find_header(object_being_registered_address - 4096) together with GC_gc_no would also be somewhat interesting. Does this application use some flavor of weak references? If so, which one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
next prev parent reply other threads:[~2004-11-01 20:44 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-11-01 17:21 [Bug libgcj/18266] New: " ovidr at users dot sourceforge dot net 2004-11-01 17:22 ` [Bug libgcj/18266] " ovidr at users dot sourceforge dot net 2004-11-01 20:44 ` Hans dot Boehm at hp dot com [this message] 2004-11-01 22:08 ` ovidr at users dot sourceforge dot net 2004-11-08 3:00 ` ovidr at users dot sourceforge dot net 2004-11-08 19:56 ` Hans dot Boehm at hp dot com 2004-11-08 20:28 ` ovidr at users dot sourceforge dot net 2004-11-25 1:50 ` Hans dot Boehm at hp dot com 2004-11-25 3:25 ` tromey at gcc dot gnu dot org 2004-11-25 3:26 ` tromey at gcc dot gnu dot org 2004-12-02 13:43 ` pinskia at gcc dot gnu dot org 2005-05-17 20:40 ` daney at gcc dot gnu dot org 2005-05-17 20:47 ` pinskia at gcc dot gnu dot org 2005-06-08 21:14 ` ovidr at users dot sourceforge dot net 2005-06-09 5:11 ` Hans dot Boehm at hp dot com 2005-06-20 16:25 ` ovidr at users dot sourceforge dot net 2005-07-19 15:21 ` ovidr at users dot sourceforge dot net [not found] <bug-18266-7936@http.gcc.gnu.org/bugzilla/> 2006-03-08 19:27 ` tromey at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20041101204421.30244.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).