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:52:01 +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 1084978566 24725 80.91.224.253 (19 May 2004 14:56:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 May 2004 14:56:06 +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 16:55:51 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 1BQSU2-0005S6-00 for ; Wed, 19 May 2004 16:55: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 1BQSU2-0000vE-00 for ; Wed, 19 May 2004 16:55: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 1BQRyU-0002Sj-S6 for emacs-devel@quimby.gnus.org; Wed, 19 May 2004 10:23:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BQRx4-0002AX-Hp for emacs-devel@gnu.org; Wed, 19 May 2004 10:21:46 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BQQek-0005Rk-A4 for emacs-devel@gnu.org; Wed, 19 May 2004 08:59:19 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1BQQei-0005Qq-LR for emacs-devel@gnu.org; Wed, 19 May 2004 08:58:45 -0400 Original-Received: (qmail 26268 invoked from network); 19 May 2004 12:52:01 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 19 May 2004 12:52:01 -0000 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 68 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:23711 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23711 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? > Found another case where a stack pointer points to bogus data, this time in Flet, variable *temps: DEFUN ("let", Flet, Slet, 1, UNEVALLED, 0, doc: /* Bind variables according to VARLIST then eval BODY. The value of the last form in BODY is returned. Each element of VARLIST is a symbol (which is bound to nil) or a list (SYMBOL VALUEFORM) (which binds SYMBOL to the value of VALUEFORM). All the VALUEFORMs are evalled before any symbols are bound. usage: (let VARLIST BODY...) */) (args) Lisp_Object args; { Lisp_Object *temps, tem; register Lisp_Object elt, varlist; int count = SPECPDL_INDEX (); register int argnum; struct gcpro gcpro1, gcpro2; varlist = Fcar (args); /* Make space to hold the values to give the bound variables */ elt = Flength (varlist); temps = (Lisp_Object *) alloca (XFASTINT (elt) * sizeof (Lisp_Object)); /* Compute the values and store them in `temps' */ GCPRO2 (args, *temps); gcpro2.nvars = 0; for (argnum = 0; !NILP (varlist); varlist = Fcdr (varlist)) { QUIT; elt = Fcar (varlist); if (SYMBOLP (elt)) temps [argnum++] = Qnil; else if (! NILP (Fcdr (Fcdr (elt)))) Fsignal (Qerror, Fcons (build_string ("`let' bindings can have only one value-form"), elt)); else temps [argnum++] = Feval (Fcar (Fcdr (elt))); Here we call Feval, which -- at some point in time will trigger GC -- and "temps" is filled with random data, some of which are bogus Lisp object pointers. There may be MANY places where this happens -- it's just that with the tramp + global-auto-revert-mode cases seen so far, the number of frames on the stack is in the range 200-300, thus making the risk of triggering this kind of error bigger than what we normally see... Either we have to explicitly ensure that we never have any bogus pointer on the stack, e.g bzero all alloca'ed memory, or we must accept (i.e. ignore) bogus objects that we find via the stack. -- Kim F. Storm http://www.cua.dk