Re: Reproducible core dump in 21.1.10
ok, try this: [for 21.1]:
2000-07-04 Ben Wing <ben(a)xemacs.org>
* symbols.c (Fmapatoms): gcpro obarray, may be new (debug-continue).
(Fapropos_internal): consing + call1 = must gcpro.
Index: symbols.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/symbols.c,v
retrieving revision 1.22.2.27
diff -u -r1.22.2.27 symbols.c
--- symbols.c 2000/02/21 23:07:12 1.22.2.27
+++ symbols.c 2000/07/04 09:33:30
＠＠ -449,11 +449,15 ＠＠
*/
(function, obarray))
{
+ struct gcpro gcpro1;
+
if (NILP (obarray))
obarray = Vobarray;
obarray = check_obarray (obarray);
+ GCPRO1 (obarray);
map_obarray (obarray, mapatoms_1, &function);
+ UNGCPRO;
return Qnil;
}
＠＠ -495,14 +499,17 ＠＠
(regexp, predicate))
{
struct appropos_mapper_closure closure;
+ struct gcpro gcpro1;
CHECK_STRING (regexp);
closure.regexp = regexp;
closure.predicate = predicate;
closure.accumulation = Qnil;
+ GCPRO1 (closure.accumulation);
map_obarray (Vobarray, apropos_mapper, &closure);
closure.accumulation = Fsort (closure.accumulation, Qstring_lessp);
+ UNGCPRO;
return closure.accumulation;
}
Gunnar Evermann wrote:
cgw(a)fnal.gov (Charles G Waldman) writes on c.e.x:
> In XEmacs 21.1 (patch 10) "Capitol Reef" [Lucid] (i686-pc-linux) of
>
> I've found that I can reproducibly dump core in 21.1.10 by (ab)using C-h a
> (hyper-apropos).
>
> The recipe goes something like this - open a few buffers (I've been
> doing VM and GNUS) and do C-h a a RET, C-h a b RET, C-h a c RET, and
> so on - lots of hyper-apropos searches on very short regexps. After a
> few of these I get:
[crash in GC]
I get this as well (both in 21.1 and 21.2)
I did some digging but have to do some Real Work[TM] now. Here is how
far I got (all on 21.2):
putting a breakpoint at signal_malformed_list_error() gives far more
interesting backtraces.
The problem seems to be in Fapropos_internal() which calls
map_obarray. In our apropos_mapper() we happily accumulate the matches
in the closure by:
closure->accumulation = Fcons (symbol, closure->accumulation);
without ever protecting them from GC. Putting in some hacks to
protect them seems to solve the problem.
back in the old days (like 20.4) the closure used to be a lisp object
that was adequately protected. I couldn't find out who made the
change. The new code looks nicer and is probably faster...
Maybe the guilty party could speak up.... :-)
Gunnar
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/