From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Fix to long-standing crashes in GC Date: 19 May 2004 14:11:42 +0200 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 1084990919 27672 80.91.224.253 (19 May 2004 18:21:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 May 2004 18:21:59 +0000 (UTC) Cc: Luc Teirlinck , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 19 20:21:50 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 1BQVhO-00008Y-00 for ; Wed, 19 May 2004 20:21:50 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BQVhN-000566-00 for ; Wed, 19 May 2004 20:21:50 +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 1BQTzb-0007Vx-7E for emacs-devel@quimby.gnus.org; Wed, 19 May 2004 12:32:31 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQTvy-0006tN-ER for emacs-devel@gnu.org; Wed, 19 May 2004 12:28:46 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQSiz-0002SH-OE for emacs-devel@gnu.org; Wed, 19 May 2004 11:11:54 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1BQQ1g-0001W9-RB for emacs-devel@gnu.org; Wed, 19 May 2004 08:18:26 -0400 Original-Received: (qmail 64322 invoked from network); 19 May 2004 12:11:42 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 19 May 2004 12:11:42 -0000 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 132 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:23727 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23727 Richard Stallman writes: > 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. However, this reveals a more serious issue: YOU REALLY CANNOT RELY 100% ON STACK POINTERS ACTUALLY POINTING TO VALID DATA. When traversing down a stack pointer object, you may end up in areas of the memory which has been reused for other purposes (so it is still "valid" Lisp data, but not of the right type). So the simplest thing - IMO - is to silently ignore unrecognized items while scanning through the stack -- In the present case, there probably isn't anything wrong anywhere, GC just happens to stumble into reused memory. Here is the data pointed to by the offending stack pointer: ((# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (# . -37) (1 . 58) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 1) (# . -37) (1 . 38) ("tramp_exit_status 0 (nil 1 500 501 (16555 37172) (15086 40970) (16442 20332) 4705 33204 t (25 . 3297) -1) " . 1) (# . -106) (21 . 107) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) ("tramp_exit_status 0 " . 1) (# . -20) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) ("tramp_exit_status 0 " . 1) (# . -20) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) ("tramp_exit_status 0 " . 1) (# . -20) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) ("tramp_exit_status 0 " . 1) (# . -20) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 1) (# . -37) (1 . 38) ("tramp_exit_status 0 (nil 1 500 501 (16555 37172) (15086 40970) (16442 20332) 4705 33204 t (25 . 3297) -1) " . 1) (# . -106) (21 . 107) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) ("tramp_exit_status 0 " . 1) (# . -20) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) ("tramp_exit_status 0 " . 1) (# . -20) (" ///00db4cb378364b4e7fcfd7777f3c1b1f " . 21) (# . -37) (1 . 58) ("(nil 1 500 501 (16555 37172) (15086 40970) (16442 20332) 4705 33204 t (25 . 3297) -1) " . 1) (# . -86)) -- Kim F. Storm http://www.cua.dk