Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[gerd.moellmann@t-online.de (Gerd Moellmann)]

Paul Eggert <eggert@twinsun.com> writes:

> Thanks.  Unfortunately I know little about this area.  To illustrate
> my naivete, can I ask a couple of questions?  Why can dispnew.c's
> direct_output_for_insert get away with modifying BEG_UNCHANGED but not
> END_UNCHANGED? 

It's likely that I simply took that from old redisplay, which did the
same, assuming it suffices and without checking thorougly.  Looking at
it again, I think it would be cleaner if direct_output_for_insert
called mark_window_display_accurate to do the job.  I'll make that
change on Sunday, when I'm at home.

> Is it possible that direct_output_for_insert was called during the
> scenario that I describe ("C-x C-s" immediately followed by "a")?

It's hard to tell, but it could be.  Seeing that there are no
intervals in the buffer makes it more likely.  Do you know if the
buffer had a non-nil after-change-function?

> Also, I can run 'gdb' and print things if you like.  For example:
> 
> #3  0x00064aa8 in find_first_unchanged_at_end_row (w=0xb97, delta=0xffbedd24, 
>     delta_bytes=0xffbedd20) at xdisp.c:11169
> (gdb) p current_buffer->text[0]
> $8 = {
>   beg = 0x1eb9478 "[some long and boring text that is not relevant to the bug, I hope...........................................................................................................................................]"..., 
>   gpt = 4139, z = 8159, gpt_byte = 4139, z_byte = 8159, gap_size = 1073, 
>   modiff = 6648, save_modiff = 6647, overlay_modiff = 5544, 
>   beg_unchanged = 4137, end_unchanged = 3936, unchanged_modified = 6647, 
>   overlay_unchanged_modified = 5544, intervals = 0x0, markers = 541792076}

What I can see from that is

-- there was one modification since the last completed redisplay, because
   the modified tick in unchanged_modified is one less than modiff.

-- unchanged info says there are 4137 chars unchanged at the buffer
   start, and 3936 unchanged at the end, sum 8073, and point-max (z)
   is 8159.  This certainly doesn't fit the addition of 1 char to the
   buffer (if that was all that happened in the buffer).

Could you please try to print, in the frame for try_window_id, for
example,

  (gdb) p *it->w->current_matrix

I don't know if the matrix is still there in a core dump, so that may
fail.