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: Fix to long-standing crashes in GC Date: 19 May 2004 15:32:22 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <40A3BC23.8060000@math.ku.dk> <200405180013.i4I0Ddl15818@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085001622 9415 80.91.224.253 (19 May 2004 21:20:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 May 2004 21:20:22 +0000 (UTC) Cc: Luc Teirlinck , rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 19 23:20:10 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQYTx-000762-00 for ; Wed, 19 May 2004 23:20:09 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQYTx-0000xE-00 for ; Wed, 19 May 2004 23:20:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQY2S-0008W0-PQ for emacs-devel@quimby.gnus.org; Wed, 19 May 2004 16:51:44 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQY1V-0008GE-HD for emacs-devel@gnu.org; Wed, 19 May 2004 16:50:45 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQWnk-0007jV-Vh for emacs-devel@gnu.org; Wed, 19 May 2004 15:33:00 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BQWnj-0007iX-R0; Wed, 19 May 2004 15:32:28 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id E5CF821148; Wed, 19 May 2004 15:32:22 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id CF4938CA23; Wed, 19 May 2004 15:32:22 -0400 (EDT) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 72 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, autolearn=not spam, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 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:23736 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23736 >> Please try finding out *precisely* which stack slot >> mark_memory is currently examining. Which stack frame is it in? >> What variable is it? > Got it. > In Feval, it points to the backtrace.evalargs member. > #4 0x0816cb3e in mark_maybe_pointer (p=0x8970000) at alloc.c:3803 > (gdb) x/32 &backtrace > 0xbffe6980: 0xbffe6b10 0xbffe69b4 0xbffe69b0 0xffffffff > 0xbffe6990: 0x08970000 0xbffe6960 0x00000002 0x08185456 > ========== here > 0xbffe69a0: 0xbffe6ac0 0xbffe69d4 0xbffe69d0 0xffffffff > 0xbffe69b0: 0x087a3815 0x084458b9 0x08947f55 0x083eb11c > 0xbffe69c0: 0xbffe6b10 0xbffe69f4 0xbffe6a08 0x0818127d > 0xbffe69d0: 0x087a382d 0x084458e9 0x088c96f9 0x083eb14c > 0xbffe69e0: 0x082188bc 0x08947f3d 0xbffe6a28 0x08430d79 > 0xbffe69f0: 0x087a38c5 0x08446a81 0x085e3725 0x08430d91 > struct backtrace > { > struct backtrace *next; > Lisp_Object *function; > Lisp_Object *args; /* Points to vector of args. */ > int nargs; /* Length of vector. > If nargs is UNEVALLED, args points to slot holding > list of unevalled args */ > char evalargs; > /* Nonzero means call value of debugger when done with this operation. */ > char debug_on_exit; > }; > So setting evalargs and debug_on_exit clears the lower part of the > Lisp_Object which happened to be on the stack on entry, but not the rest > of it, so it points into a legal cons_block cell, but one which probably > isn't in use anymore. > I will install a fix for this specific issue shortly. Please show us the fix first. > However, this reveals a more serious issue: > YOU REALLY CANNOT RELY 100% ON STACK POINTERS ACTUALLY > POINTING TO VALID DATA. But that's already checked: mark_memory calls makr_maybe_object and makr_maybe_pointer, but of which check for every object whether it's currently live (which really means "allocated" in the sense that it hasn't been reclaimed by the GC yet). That's what live_consp_, live_stringp_p, ... are for. > Here is the data pointed to by the offending stack pointer: > ((# . -37) > (# . -37) > (# . -37) > (# . -37) > (# . -37) > (# . -37) I strongly suspect that we're looking at a consequence of another bug. Either this cons cell (pointed to by evalargs) is indeed live and then it should not lead to any misc_free object, or it is incorrectly considered as live (maybe because of a bug in live_cons_p, or because of a bug in the code that marks cons cells as dead in gc_sweep, or because of some wild pointer overwriting the corresponding data, ...). Stefan