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