GCPRUG in run_hooks [was Re: Another 21.2.19 crash]
[Note to FSF Emacs maintainers. This discusses an XEmacs bug.
However, this code is identical to that in FSF Emacs 20.3. So it
probably has the same bug]
Raymond Toy <toy(a)rtp.ericsson.se> writes:
I have to say, b19 has been the least stable beta for me since 21.1
or
maybe even earlier. :-(
He, its beta! Just be happy that there is new code to crash on.
Anyway both of your crashes were real bugs. This one is even very old!
In fact this bug is also in FSF 20.3
Something is in the global pre-command-hook that conses a lot I think.
#5 0xa3584 in assert_failed (file=0x2e11e0 "lisp.h",
line=640,
expr=0x2e11e8 "RECORD_TYPEP (obj, &lrecord_cons) || MARKED_RECORD_P
(obj)") at emacs.c:2672
#6 0xae30c in run_hook_with_args_in_buffer (buf=0x3dc804, nargs=1, args=0xefffe060,
cond=RUN_HOOKS_TO_COMPLETION) at eval.c:3658
A typical (X)Emacs bug. A forgotten GCPRO. This the code is
in run_hook_with_args_in_buffer
/* t indicates this hook has a local binding;
it means to run the global binding too. */
Lisp_Object globals = Fdefault_value (sym);
[..]
{
for (;
CONSP (globals) && ((cond == RUN_HOOKS_TO_COMPLETION)
|| (cond == RUN_HOOKS_UNTIL_SUCCESS
? NILP (ret)
: !NILP (ret)));
globals = XCDR (globals))
{
args[0] = XCAR (globals);
/* In a global value, t should not occur. If it does, we
must ignore it to avoid an endless loop. */
if (!EQ (args[0], Qt))
ret = Ffuncall (nargs, args);
}
}
}
Note how 'globals' is allocated on the stack but never GCPRO'ed, but
Ffuncall is called and this can garbage-collect.
(The crash is in the XCDR(globals) ).
Jan