possible bug in redisplay
Julian Bradfield writes:
A couple of days ago, my XEmacs crashed when I did something as
innocent as narrowing-to-region and then M-<. I haven't seen this
before, but it turned out to be repeatable - but heavily dependent on
the exact file, region, font setup, etc, so I didn't reproduce it in a
vanilla standard XEmacs.
Of course, this is my heavily modified Unicode-internal fork of
21.4,
but as far as I can see, nothing I've done is implicated in the
problem.
On the other hand, you'd think we would have seen this before, given
that redisplay is entered very frequently. Also, the fact that it is
caught by an assert suggests that somebody thinks that the invariant
is satisfied by the code.
There's another return point inside if (pixheight < 0) {...}
before that loop, in which either prev_pos or cur_pos is returned,
without checking whether they're less than BUF_BEGV. It may be that
prev_pos can't be, because it would have been caught by the other
check in the previous iteration of the main loop; but I can't see why
cur_pos might not be, as indeed it was in the crash I saw.
Well, it seems that the line start cache gets blown away rather
frequently. Point itself should be warped to be > BUF_BEGV by the
narrowing code, so cur_pos should be initialized to something sane.
How about a sledgehammer check on the 'start' members of the line
cache in the validate function?
I added a check at that point, and the crash went away.
Slowing down redisplay is not a good thing. It would be really nice
if you could either find a way to reproduce in vanilla XEmacs (best),
or give us the values of the "override" member and whether the
line_start_cache exists at the point of the crash.
If we can't localize the bug better, then making a check for cur_pos
= BUF_BEGV somewhere is the right thing to do, of course.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta