[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix to long-standing crashes in GC

From: Kim F. Storm
Subject: Re: Fix to long-standing crashes in GC
Date: 19 May 2004 14:52:01 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Richard Stallman <address@hidden> 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...)  */)
     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))
      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 
        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 <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]