Re: Reproducible core dump in 21.1.10

Saturday, 15 July 2000

I have applied this to the 21.1 branch for XEmacs.
It will appear in 21.1.11 Real Soon Now.

  - vin

...
>>>> On Tue, 04 Jul 2000, Ben Wing <ben(a)666.com&gt;
said: 
Ben> ok, try this: [for 21.1]:
Ben> 2000-07-04  Ben Wing  <ben(a)xemacs.org&gt;

Ben>  * symbols.c (Fmapatoms): gcpro obarray, may be new (debug-continue).
Ben>  (Fapropos_internal): consing + call1 = must gcpro.

Ben> Index: symbols.c
Ben> ===================================================================
Ben> RCS file: /usr/CVSroot/XEmacs/xemacs/src/symbols.c,v
Ben> retrieving revision 1.22.2.27
Ben> diff -u -r1.22.2.27 symbols.c
Ben> --- symbols.c 2000/02/21 23:07:12 1.22.2.27
Ben> +++ symbols.c 2000/07/04 09:33:30
Ben> ＠＠ -449,11 +449,15 ＠＠
Ben>  */
Ben>         (function, obarray))
Ben>  {
Ben> +  struct gcpro gcpro1;
Ben> +
Ben>    if (NILP (obarray))
Ben>      obarray = Vobarray;
Ben>    obarray = check_obarray (obarray);

Ben> +  GCPRO1 (obarray);
Ben>    map_obarray (obarray, mapatoms_1, &function);
Ben> +  UNGCPRO;
Ben>    return Qnil;
Ben>  }

Ben> ＠＠ -495,14 +499,17 ＠＠
Ben>         (regexp, predicate))
Ben>  {
Ben>    struct appropos_mapper_closure closure;
Ben> +  struct gcpro gcpro1;

Ben>    CHECK_STRING (regexp);

Ben>    closure.regexp = regexp;
Ben>    closure.predicate = predicate;
Ben>    closure.accumulation = Qnil;
Ben> +  GCPRO1 (closure.accumulation);
Ben>    map_obarray (Vobarray, apropos_mapper, &closure);
Ben>    closure.accumulation = Fsort (closure.accumulation, Qstring_lessp);
Ben> +  UNGCPRO;
Ben>    return closure.accumulation;
Ben>  }

Ben> 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> --
Ben> Ben

Ben> In order to save my hands, I am cutting back on my mail.  I also write
Ben> as succinctly as possible -- please don't be offended.  If you send me
Ben> mail, you _will_ get a response, but please be patient, especially for
Ben> XEmacs-related mail.  If you need an immediate response and it is not
Ben> apparent in your message, please say so.  Thanks for your understanding.

Ben> See also http://www.666.com/ben/chronic-pain/

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998