Re: Mysterious redisplay problem and a trap in xdisp.c

[Kim F. Storm]

address@hidden (Gerd Moellmann) writes:

> address@hidden (Kim F. Storm) writes:
> 
> 
> [...]
> 
> > I have now tracked the problem down to the following change:
> > 
> > 2001-12-11  Andrew Innes  <address@hidden>
> > 
> >     * insdel.c (make_gap) [DOUG_LEA_MALLOC]: Call make_gap_smaller if
> >     arg is negative.
> > 
> > If I comment out the call to make_gap_smaller in make_gap, the problem
> > goes away!
> 
> Hm, my theory, which might well be completely wrong, would be that a GC
> during redisplay, via make_gap_smaller, changes the address of the
> characters to be displayed, and that some code in redisplay doesn't
> protect itself against that address change.

I did some more digging, and discovered that make_gap_smaller does not
preserves the value of BEG_UNCHANGED around the gap manipulation.

In most cases, it will have moved that offset *ahead* in the buffer -
i.e.  redisplay does not look for buffer changes at the place where it
actually happened...  Why that results in inserting a newline I don't
know - or whether it can explain the traps/aborts I've seen.

In any case, I just committed a fix to restore BEG_UNCHANGED after the
gap reduction, and it seems to have fixed the problem.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk