Emacs 21.2 core dump in find_first_unchanged_at_end_row

Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Paul Eggert]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars)
 on sic.twinsun.com
configured using `configure  --prefix=/opt/reb --with-gcc --with-pop --x-includes=/opt/sfw/include:/usr/openwin/include --x-libraries=/opt/sfw/lib:/usr/openwin/lib'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

This one is hard to describe.  I had edited using Emacs for quite
some time, and and just saved a file.  I was starting to do something
else (sorry, can't remember what), and Emacs dumped core.

Here is a GDB backtrace of the core dump:

#0  0xfed9c840 in ?? ()
#1  0xfed9b86c in ?? ()
#2  0x000d866c in abort () at emacs.c:387
#3  0x00064aa8 in find_first_unchanged_at_end_row (w=0xb97, delta=0xffbedd24, 
    delta_bytes=0xffbedd20) at xdisp.c:11169
#4  0x00065240 in try_window_id (w=0xb3e800) at xdisp.c:11585
#5  0x00062f74 in redisplay_window (window=1085532160, just_this_one_p=0)
    at xdisp.c:10237
#6  0x0005f9d8 in redisplay_windows (window=1085532160) at xdisp.c:9224
#7  0x0005e8dc in redisplay_internal (preserve_echo_area=4909056)
    at xdisp.c:8828
#8  0x000de2e0 in read_char (commandflag=1, nmaps=2, maps=0xffbee968, 
    prev_event=271256580, used_mouse_menu=0xffbee9f0) at keyboard.c:2272
#9  0x000e54b8 in read_key_sequence (keybuf=0xffbeeb28, bufsize=30, 
    prompt=271256580, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at keyboard.c:8180
#10 0x000db378 in command_loop_1 () at keyboard.c:1440
#11 0x0013cecc in internal_condition_case (bfun=0xdb114 <command_loop_1>, 
    handlers=271378628, hfun=0xdac7c <cmd_error>) at eval.c:1267
#12 0x000dafa4 in command_loop_2 () at keyboard.c:1245
#13 0x0013ca34 in internal_catch (tag=271330980, 
    func=0xdaf80 <command_loop_2>, arg=271256580) at eval.c:1030
#14 0x000daf30 in command_loop () at keyboard.c:1224
#15 0x000da9e8 in recursive_edit_1 () at keyboard.c:950
#16 0x000dab44 in Frecursive_edit () at keyboard.c:1006
#17 0x000d9908 in main (argc=0, argv=0xffbef06c, envp=0x197c00) at emacs.c:1547

Here are some variable values that may help you diagnose the problem.
Emacs aborted because row->enabled_p is zero.

(gdb) p row->enabled_p
$4 = 0
(gdb) p first_text_row
$5 = (struct glyph_row *) 0xba3000
(gdb) p row
$6 = (struct glyph_row *) 0xba4634
(gdb) p row - first_text_row
$7 = 49
(gdb) p last_unchanged_pos
$8 = 33554432
(gdb) p last_unchanged_pos_old 
$9 = 4223
(gdb) p *delta
$10 = 1
(gdb) p *delta_bytes
$11 = 1
(gdb) p Z_old
$12 = 4223
(gdb) p Z_BYTE_old
$13 = 8158
(gdb) p *row
$14 = {glyphs = {0xb96000, 0xb96000, 0xb966b8, 0xb966b8}, used = {0, 22, 0}, 
  x = 0, y = 936, pixel_width = 154, ascent = 11, height = 13, 
  phys_ascent = 11, phys_height = 13, visible_height = -13, hash = 76364866, 
  start = {pos = {charpos = 4643, bytepos = 4643}, overlay_string_index = -1, 
    string_pos = {charpos = -1, bytepos = -1}, dpvec_index = -1}, end = {
    pos = {charpos = 4665, bytepos = 4665}, overlay_string_index = -1, 
    string_pos = {charpos = -1, bytepos = -1}, dpvec_index = -1}, 
  enabled_p = 0, inverse_p = 0, truncated_on_left_p = 0, 
  truncated_on_right_p = 0, overlay_arrow_p = 0, continued_p = 0, 
  displays_text_p = 1, ends_at_zv_p = 0, fill_line_p = 0, 
  indicate_empty_line_p = 0, contains_overlapping_glyphs_p = 0, 
  full_width_p = 0, mode_line_p = 0, overlapped_p = 0, 
  ends_in_middle_of_char_p = 0, starts_in_middle_of_char_p = 0, 
  overlapping_p = 0, mouse_face_p = 0, ends_in_newline_from_string_p = 0, 
  continuation_lines_width = 0}

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Eli Zaretskii]

> From: Paul Eggert <eggert@twinsun.com>
> Date: Wed, 27 Mar 2002 16:44:08 -0800 (PST)
> 
> This one is hard to describe.  I had edited using Emacs for quite
> some time, and and just saved a file.  I was starting to do something
> else (sorry, can't remember what), and Emacs dumped core.

"xbacktrace" should show a Lisp backtrace which will tell what Emacs
was doing, and might refresh your memory about your keystrokes at that
time.

Thanks for the report.

Gerd, do you have any suggestions?

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Paul Eggert]

> Date: Thu, 28 Mar 2002 10:34:47 +0200
> From: "Eli Zaretskii" <eliz@is.elta.co.il>
> 
> "xbacktrace" should show a Lisp backtrace which will tell what Emacs
> was doing, and might refresh your memory about your keystrokes at that
> time.

Unfortunately "xbacktrace" reports nothing, as backtrace_list is zero.

I do remember one other thing.  Right after I saved the file, I must
have accidentally typed one more "a" character into the buffer at a
relatively random location in the file.  This caused emacs to create a
"#" file with the extra "a" in it, which I found after the core dump.
I think this must have happened just before Emacs dumped core.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Gerd Moellmann]

Paul Eggert <eggert@twinsun.com> writes:

> > Date: Thu, 28 Mar 2002 10:34:47 +0200
> > From: "Eli Zaretskii" <eliz@is.elta.co.il>
> > 
> > "xbacktrace" should show a Lisp backtrace which will tell what Emacs
> > was doing, and might refresh your memory about your keystrokes at that
> > time.
> 
> Unfortunately "xbacktrace" reports nothing, as backtrace_list is zero.

I think this is normal, given the GDB backtrace you sent.

> I do remember one other thing.  Right after I saved the file, I must
> have accidentally typed one more "a" character into the buffer at a
> relatively random location in the file.  This caused emacs to create a
> "#" file with the extra "a" in it, which I found after the core dump.
> I think this must have happened just before Emacs dumped core.

IIRC, the last time something like that came up, it was caused by
bogus unchanged information in the buffer
(BEG_UNCHANGED/END_UNCHANGED).  Maybe it's worth looking at that,
although it might be hard to reconstruct what happened.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Paul Eggert]

> From: gerd.moellmann@t-online.de (Gerd Moellmann)
> Date: 29 Mar 2002 11:20:40 +0100

> > I do remember one other thing.  Right after I saved the file, I must
> > have accidentally typed one more "a" character into the buffer at a
> > relatively random location in the file.  This caused emacs to create a
> > "#" file with the extra "a" in it, which I found after the core dump.
> > I think this must have happened just before Emacs dumped core.
> 
> IIRC, the last time something like that came up, it was caused by
> bogus unchanged information in the buffer
> (BEG_UNCHANGED/END_UNCHANGED).  Maybe it's worth looking at that,
> although it might be hard to reconstruct what happened.

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

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}

Unfortunately the text itself is part of some private correspondence,
and I can't simply give you the core file.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[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.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Paul Eggert]

> From: gerd.moellmann@t-online.de (Gerd Moellmann)
> Date: 29 Mar 2002 21:25:15 +0100

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

Not sure, but I think not.  I believe the buffer was for a file that
is under VC control, but I don't think VC messes with
after-change-function.

> -- 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).

Yes, that looked weird to me as well.  My memory _could_ be wrong; or
perhaps I typed C-y or something like that by mistake; but all I remember
was typing C-x C-s a.

> Could you please try to print, in the frame for try_window_id, for
> example,
> 
>   (gdb) p *it->w->current_matrix

$1 = {pool = 0x0, rows = 0xba3000, rows_allocated = 75, nrows = 75, 
  matrix_x = 0, matrix_y = 0, matrix_w = 86, matrix_h = 75, window_left_x = 0, 
  window_top_y = 0, window_height = 923, window_width = 553, 
  window_vscroll = 0, left_margin_glyphs = 0, right_margin_glyphs = 0, 
  no_scrolling_p = 0, header_line_p = 0, method = '\000' <repeats 511 times>, 
  buffer = 0xb3e200, begv = 1, zv = 8158}

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Gerd Moellmann]

Paul Eggert <eggert@twinsun.com> writes:

> > From: gerd.moellmann@t-online.de (Gerd Moellmann)
> > Date: 29 Mar 2002 21:25:15 +0100
> 
> > > 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?
> 
> Not sure, but I think not.  I believe the buffer was for a file that
> is under VC control, but I don't think VC messes with
> after-change-function.

If there's no after-change-function, it's even more likely that 
direct_output_for_insert got called.

> > -- 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).
> 
> Yes, that looked weird to me as well.  My memory _could_ be wrong; or
> perhaps I typed C-y or something like that by mistake; but all I remember
> was typing C-x C-s a.
> 
> > Could you please try to print, in the frame for try_window_id, for
> > example,
> > 
> >   (gdb) p *it->w->current_matrix
> 
> $1 = {pool = 0x0, rows = 0xba3000, rows_allocated = 75, nrows = 75, 
>   matrix_x = 0, matrix_y = 0, matrix_w = 86, matrix_h = 75, window_left_x = 0, 
>   window_top_y = 0, window_height = 923, window_width = 553, 
>   window_vscroll = 0, left_margin_glyphs = 0, right_margin_glyphs = 0, 
>   no_scrolling_p = 0, header_line_p = 0, method = '\000' <repeats 511 times>, 
>   buffer = 0xb3e200, begv = 1, zv = 8158}

There is the `a'---the value of point-max at the time the last
redisplay completed was 8158, one char less than there's now in the
buffer.  Which means the unchanged information is indeed screwed up
and caused the crash, indirectly.

Did you compile Emacs with -DGLYPH_DEBUG?  If yes, could you please

  (gdb) p redisplay_history[history_idx - N].trace

for N from 1 to 5, say.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Paul Eggert]

> From: gerd.moellmann@t-online.de (Gerd Moellmann)
> Date: 29 Mar 2002 23:56:53 +0100
> 
> Did you compile Emacs with -DGLYPH_DEBUG?

Sorry, no.  It was a fairly vanilla build.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Eli Zaretskii]

> From: Paul Eggert <eggert@twinsun.com>
> Date: Fri, 29 Mar 2002 14:36:04 -0800 (PST)
> 
> > -- 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).
> 
> Yes, that looked weird to me as well.  My memory _could_ be wrong; or
> perhaps I typed C-y or something like that by mistake; but all I remember
> was typing C-x C-s a.

In case it's important to know what exactly did you type, you should
be able to find that in recent_keys, which is a Lisp vector.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Gerd Moellmann]

Paul Eggert <eggert@twinsun.com> writes:

> > From: gerd.moellmann@t-online.de (Gerd Moellmann)
> > Date: 29 Mar 2002 23:56:53 +0100
> > 
> > Did you compile Emacs with -DGLYPH_DEBUG?
> 
> Sorry, no.  It was a fairly vanilla build.

Then I think there's no way of proving that direct_output_for_insert
ran.

I have a strong gut feeling though it did get called, and that not
setting END_UNCHANGED in direct_output_for_insert has something to do
with the bogus unchanged info.  Alas, I don't see a way to prove that,
so I can only trust my gut.

What I've done is call mark_window_display_accurate in
direct_output_for_insert.  That should be done anyway, and removes any
doubt that direct_output_for_insert DTRT with unchanged info in the
future.  A patch is at the end of this mail.

I've installed this in HEAD.  Could someone please tell me if the RC
branch is still in use?  If so, I think this should be installed in the
branch, too.

*** dispnew.c	2002/03/30 11:50:25	1.302
--- dispnew.c	2002/03/30 11:51:51
***************
*** 3655,3668 ****
    fflush (stdout);
  
    TRACE ((stderr, "direct output for insert\n"));
! 
!   UNCHANGED_MODIFIED = MODIFF;
!   BEG_UNCHANGED = GPT - BEG;
!   XSETFASTINT (w->last_point, PT);
!   w->last_cursor = w->cursor;
!   XSETFASTINT (w->last_modified, MODIFF);
!   XSETFASTINT (w->last_overlay_modified, OVERLAY_MODIFF);
! 
    redisplay_performed_directly_p = 1;
    return 1;
  }
--- 3655,3661 ----
    fflush (stdout);
  
    TRACE ((stderr, "direct output for insert\n"));
!   mark_window_display_accurate (it.window, 1);
    redisplay_performed_directly_p = 1;
    return 1;
  }

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Richard Stallman]

One annoying new bug was reported in 21.2, so we might make
another release from it.  So you may as well put this in RC.

Re: Emacs 21.2 core dump in find_first_unchanged_at_end_row

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

> One annoying new bug was reported in 21.2, so we might make
> another release from it.  So you may as well put this in RC.

Done.