From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GC crashes Date: 04 Dec 2003 10:48:21 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20031124.110938.193696628.wl@gnu.org> <200311260203.LAA26808@etlken.m17n.org> <20031128.103107.41640217.wl@gnu.org> <200312011240.VAA05762@etlken.m17n.org> <200312022337.IAA02026@etlken.m17n.org> <200312032319.IAA04473@etlken.m17n.org> <200312040112.KAA04711@etlken.m17n.org> <200312040221.LAA04807@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070553451 2914 80.91.224.253 (4 Dec 2003 15:57:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 15:57:31 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 16:57:28 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARvr6-0000gj-00 for ; Thu, 04 Dec 2003 16:57:28 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARvr5-0001Fn-00 for ; Thu, 04 Dec 2003 16:57:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARwit-0007RI-8x for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 11:53:03 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARwhZ-0007QK-6m for emacs-devel@gnu.org; Thu, 04 Dec 2003 11:51:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARwh0-0007Es-2y for emacs-devel@gnu.org; Thu, 04 Dec 2003 11:51:37 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARwgy-0007E3-Gc for emacs-devel@gnu.org; Thu, 04 Dec 2003 11:51:04 -0500 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (8.12.9/8.12.9) with ESMTP id hB4FmLbj016312; Thu, 4 Dec 2003 10:48:22 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id B7BDC3CFD9; Thu, 4 Dec 2003 10:48:21 -0500 (EST) Original-To: Kenichi Handa In-Reply-To: <200312040221.LAA04807@etlken.m17n.org> Original-Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner: Found to be clean X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18373 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18373 > I've just found one fact about a weak hash table. > Even if composite.c makes a weak hash table in > syms_of_composite (thus it is stored in Vweak_hash_tables > and dumped), Vweak_hash_tables is intialized to Qnil in > init_fns () at Emacs startup time. Ha! That's a bug. > Does it mean that we should not dump a weak hash table? No, it just means we have to change init_fns. > Do you think it relates to the current problem? Sounds likely. IIUC the above problem means that the mark phase of the GC will (correctly) not look at the hash-table's elements (because the table is marked as weak), but the elements that get GC'd will not be properly removed from the table because that is done via Vweak_hash_tables. I.e. the hash table will end up with dangling pointers. Stefan