Mysterious redisplay problem and a trap in xdisp.c

Mysterious redisplay problem and a trap in xdisp.c

[Kim F. Storm]

I was trying to track down a redisplay problem I've seen lately with
the CVS emacs:

While typing in some text in a buffer, emacs suddenly decides to
insert a new line instead of the character I typed.  But if I do C-l,
there is only one line, and the character I typed magically reappears.

I've only seen this with column-number-mode turned on, so the rest of
you may not have noticed.

When this happens, the column number continues to increment relative
to the original line start (and the bogus line wrap), but continuation
glyphs are shown "correctly" in the fringe when the second line
reaches the right margin and wraps into the third line.

Anyway, at some point, emacs decided to crash (seemingly immediately after
inserting one of those bogus newlines).  Unfortunately, that specific
incarnation of emacs was not running under GDB, but I have to core file
if there is anything specific you want me to look into...:


(gdb) bt
#0  0x402c9d41 in __kill () from /lib/libc.so.6
#1  0x80cd041 in fatal_error_signal (sig=6) at emacs.c:377
#2  0x402c9c68 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#3  0x806b46e in find_first_unchanged_at_end_row (w=0x8b1ce10, delta=0xbfffea40, delta_bytes=0xbfffea44) at xdisp.c:11208
#4  0x806be26 in try_window_id (w=0x8b1ce10) at xdisp.c:11624
#5  0x80693e9 in redisplay_window (window=1219612176, just_this_one_p=1) at xdisp.c:10276
#6  0x8066db4 in redisplay_window_1 (window=1219612176) at xdisp.c:9266
#7  0x811db48 in internal_condition_case_1 (bfun=0x8066d94 <redisplay_window_1>, arg=1219612176, handlers=405306396,
    hfun=0x8066d50 <redisplay_window_error>) at eval.c:1338
#8  0x8066666 in redisplay_internal (preserve_echo_area=0) at xdisp.c:8898
#9  0x806536e in redisplay () at xdisp.c:8278
#10 0x80d0c1d in read_char (commandflag=1, nmaps=4, maps=0xbffff5cc, prev_event=405209980, used_mouse_menu=0xbffff614)
    at keyboard.c:2286
#11 0x80d713c in read_key_sequence (keybuf=0xbffff710, bufsize=30, prompt=405209980, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8289
#12 0x80cf87c in command_loop_1 () at keyboard.c:1441
#13 0x811da54 in internal_condition_case (bfun=0x80cf5bc <command_loop_1>, handlers=405306396, hfun=0x80cf254 <cmd_error>)
    at eval.c:1298
#14 0x80cf4c5 in command_loop_2 () at keyboard.c:1247
#15 0x811d652 in internal_catch (tag=405267724, func=0x80cf4a8 <command_loop_2>, arg=405209980) at eval.c:1058
#16 0x80cf47f in command_loop () at keyboard.c:1226
#17 0x80cf050 in recursive_edit_1 () at keyboard.c:952
#18 0x80cf15d in Frecursive_edit () at keyboard.c:1008
#19 0x80ce238 in main (argc=1, argv=0xbffffc54, envp=0xbffffc5c) at emacs.c:1607
(gdb) up 3
#3  0x806b46e in find_first_unchanged_at_end_row (w=0x8b1ce10, delta=0xbfffea40, delta_bytes=0xbfffea44) at xdisp.c:11208
11208               abort ();
(gdb) list
11203         /* Search backward from ROW for a row displaying a line that
11204            starts at a minimum position >= last_unchanged_pos_old.  */
11205         for (; row > first_text_row; --row)
11206           {
11207             if (!row->enabled_p || !MATRIX_ROW_DISPLAYS_TEXT_P (row))
11208               abort ();
11209
11210             if (MATRIX_ROW_START_CHARPOS (row) >= last_unchanged_pos_old)
11211               row_found = row;
11212           }



-- 
Kim F. Storm  <storm@cua.dk>


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Eli Zaretskii]

> From: "Kim F. Storm" <storm@cua.dk>
> Date: Thu,  7 Feb 2002 12:59:30 +0000 (GMT)
> 
> While typing in some text in a buffer, emacs suddenly decides to
> insert a new line instead of the character I typed.  But if I do C-l,
> there is only one line, and the character I typed magically reappears.
> 
> I've only seen this with column-number-mode turned on, so the rest of
> you may not have noticed.
> 
> When this happens, the column number continues to increment relative
> to the original line start (and the bogus line wrap), but continuation
> glyphs are shown "correctly" in the fringe when the second line
> reaches the right margin and wraps into the third line.
> 
> Anyway, at some point, emacs decided to crash (seemingly immediately after
> inserting one of those bogus newlines).

IMHO, the initial problem is that newline Emacs inserts where it
shouldn't have; find the code which is guilty of that, and you've
found your villain.  The crash (actually, Emacs doesn't crash, it
aborts itself) clearly shows that the display code found an
impossible condition: a glyph row was not enabled.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Richard Stallman]

    #3  0x806b46e in find_first_unchanged_at_end_row (w=0x8b1ce10, delta=0xbfffea40, delta_bytes=0xbfffea44) at xdisp.c:11208
    #4  0x806be26 in try_window_id (w=0x8b1ce10) at xdisp.c:11624

You may as well look at the data in those frames and see
what you can see about the proximal cause of the crash.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Kim F. Storm]

I've made some progress on this (and found a possible work-around),
but no real explanation of what's wrong.  Read on...

"Kim F. Storm" <storm@cua.dk> writes:

> I was trying to track down a redisplay problem I've seen lately with
> the CVS emacs:
> 
> While typing in some text in a buffer, emacs suddenly decides to
> insert a new line instead of the character I typed.  But if I do C-l,
> there is only one line, and the character I typed magically reappears.
> 
> I've only seen this with column-number-mode turned on, so the rest of
> you may not have noticed.
> 
> When this happens, the column number continues to increment relative
> to the original line start (and the bogus line wrap), but continuation
> glyphs are shown "correctly" in the fringe when the second line
> reaches the right margin and wraps into the third line.
> 

I made a small change to redisplay_internal so that instead of testing
on w->column_number_displayed, it just sets w->update_mode_line
unconditionally, i.e.

#if 0
  /* If %c is in the mode line, update it if needed.  */
  if (!NILP (w->column_number_displayed)
      /* This alternative quickly identifies a common case
	 where no change is needed.  */
      && !(PT == XFASTINT (w->last_point)
	   && XFASTINT (w->last_modified) >= MODIFF
	   && XFASTINT (w->last_overlay_modified) >= OVERLAY_MODIFF)
      && XFASTINT (w->column_number_displayed) != current_column ())
#endif
    w->update_mode_line = Qt; 

This makes the problem appear without enabling column-number-mode.

In addition, I set the modeline-format to "-" and the problem still
appears, so it is not related to the mode-line as such. 

However, if I turn off the tool-bar (M-x tool-bar-mode), the
problem seems to disappear.


I have now tracked the problem down to the following change:

2001-12-11  Andrew Innes  <andrewi@gnu.org>

	* 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!

I placed a breakpoint on entry to make_gap_smaller, and except for a
few calls during startup, it seems that every time it is called
the false newline problem is seen.

But it is never(?) called when I turn off the tool-bar (except if I
make an explicit M-x garbage-collect) But maybe that is because using
the tool-bar causes the automatic garbage collection to happen more
frequently.


Here are some examples of contents of current_buffer->text on entry
and exit from that function when the problem is seen:


Breakpoint 3, make_gap_smaller (nbytes_removed=1728) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$19 = {
  beg = 0x84f4ca0 ";; This buffer is for notes you don't want to save, and for Lis
p evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 208,
  z = 1044,
  gpt_byte = 208,
  z_byte = 1044,
  gap_size = 1832,
  modiff = 1088,
  save_modiff = 0,
  overlay_modiff = 2,
  beg_unchanged = 207,
  end_unchanged = 836,
  unchanged_modified = 1088,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674307420
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=1728) at insdel.c:587
make_gap (nbytes_added=-1728) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$20 = {
  beg = 0x84f4ca0 ";; This buffer is for notes you don't want to save, and for Lis
p evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 208,
  z = 1044,
  gpt_byte = 208,
  z_byte = 1044,
  gap_size = 104,
  modiff = 1088,
  beg_unchanged = 1147,
  end_unchanged = 836,
  unchanged_modified = 1088,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674307420
}
(gdb)

Breakpoint 3, make_gap_smaller (nbytes_removed=1748) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$21 = {
  beg = 0x84d0870 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1170,
  z = 1274,
  gpt_byte = 1170,
  z_byte = 1274,
  gap_size = 1875,
  modiff = 1318,
  save_modiff = 0,
  overlay_modiff = 2,
  beg_unchanged = 1169,
  end_unchanged = 104,
  unchanged_modified = 1318,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674306720
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=1748) at insdel.c:587
make_gap (nbytes_added=-1748) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$22 = {
  beg = 0x84d0870 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1170,
  z = 1274,
  gpt_byte = 1170,
  z_byte = 1274,
  gap_size = 127,
  modiff = 1318,
  save_modiff = 0,
  overlay_modiff = 2,
  beg_unchanged = 1400,
  end_unchanged = 104,
  unchanged_modified = 1318,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674306720
}
(gdb)  


If I try an explicit garbage collection, the following behaviour
is seen:
 
Breakpoint 3, make_gap_smaller (nbytes_removed=983) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$26 = {
  beg = 0x84e44c0 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1344,
  z = 4019,
  gpt_byte = 1344,
  z_byte = 4019,
  gap_size = 1384,
  modiff = 4063,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 1343,
  end_unchanged = 2675,
  unchanged_modified = 4063,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675045032
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=983) at insdel.c:587
make_gap (nbytes_added=-983) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$27 = {
  beg = 0x84e44c0 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1344,
  z = 4019,
  gpt_byte = 1344,
  z_byte = 4019,
  gap_size = 401,
  modiff = 4063,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 4419,
  end_unchanged = 2675,
  unchanged_modified = 4063,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675045032
}
(gdb)          


 
Breakpoint 3, make_gap_smaller (nbytes_removed=1322) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$29 = {
  beg = 0x84b78d8 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 887,
  z = 4636,
  gpt_byte = 887,
  z_byte = 4636,
  gap_size = 1785,
  modiff = 4680,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 886,
  end_unchanged = 3749,
  unchanged_modified = 4680,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675044292
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=1322) at insdel.c:587
make_gap (nbytes_added=-1322) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$30 = {
  beg = 0x84b78d8 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 887,
  z = 4636,
  gpt_byte = 887,
  z_byte = 4636,
  gap_size = 463,
  modiff = 4680,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 5098,
  end_unchanged = 3749,
  unchanged_modified = 4680,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675044292
}
(gdb) 


I have tried hard to understand what's going on, but maybe someone
else is able to see what might be wrong here...

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


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 08 Feb 2002 21:50:50 +0100
> 
> But it is never(?) called when I turn off the tool-bar (except if I
> make an explicit M-x garbage-collect) But maybe that is because using
> the tool-bar causes the automatic garbage collection to happen more
> frequently.

You could verify this by setting gc-cons-threshold to a small value.

> I have tried hard to understand what's going on, but maybe someone
> else is able to see what might be wrong here...

I suggest to CC Gerd Moellmann with this discussion (and forward him
the previous messages with important findings).

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Kim F. Storm]

Hi Gerd,
Eli suggested I forwarded this to you.
There seem to be a problem with make_gap_smaller.

Since the posting below, I have tried the following steps (after starting emacs -q):

1) Setting gc-cons-threshold to 100 -> problem does not occur
2) M-x column-number-mode  -> problem occurs
3) M-x tool-bar-mode -> problem goes away

"Kim F. Storm" <storm@cua.dk> writes:

> I was trying to track down a redisplay problem I've seen lately with
> the CVS emacs:
> 
> While typing in some text in a buffer, emacs suddenly decides to
> insert a new line instead of the character I typed.  But if I do C-l,
> there is only one line, and the character I typed magically reappears.
> 
> I've only seen this with column-number-mode turned on, so the rest of
> you may not have noticed.
> 
> When this happens, the column number continues to increment relative
> to the original line start (and the bogus line wrap), but continuation
> glyphs are shown "correctly" in the fringe when the second line
> reaches the right margin and wraps into the third line.
> 

I made a small change to redisplay_internal so that instead of testing
on w->column_number_displayed, it just sets w->update_mode_line
unconditionally, i.e.

#if 0
  /* If %c is in the mode line, update it if needed.  */
  if (!NILP (w->column_number_displayed)
      /* This alternative quickly identifies a common case
	 where no change is needed.  */
      && !(PT == XFASTINT (w->last_point)
	   && XFASTINT (w->last_modified) >= MODIFF
	   && XFASTINT (w->last_overlay_modified) >= OVERLAY_MODIFF)
      && XFASTINT (w->column_number_displayed) != current_column ())
#endif
    w->update_mode_line = Qt; 

This makes the problem appear without enabling column-number-mode.

In addition, I set the modeline-format to "-" and the problem still
appears, so it is not related to the mode-line as such. 

However, if I turn off the tool-bar (M-x tool-bar-mode), the
problem seems to disappear.


I have now tracked the problem down to the following change:

2001-12-11  Andrew Innes  <andrewi@gnu.org>

	* 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!

I placed a breakpoint on entry to make_gap_smaller, and except for a
few calls during startup, it seems that every time it is called
the false newline problem is seen.

But it is never(?) called when I turn off the tool-bar (except if I
make an explicit M-x garbage-collect) But maybe that is because using
the tool-bar causes the automatic garbage collection to happen more
frequently.


Here are some examples of contents of current_buffer->text on entry
and exit from that function when the problem is seen:


Breakpoint 3, make_gap_smaller (nbytes_removed=1728) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$19 = {
  beg = 0x84f4ca0 ";; This buffer is for notes you don't want to save, and for Lis
p evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 208,
  z = 1044,
  gpt_byte = 208,
  z_byte = 1044,
  gap_size = 1832,
  modiff = 1088,
  save_modiff = 0,
  overlay_modiff = 2,
  beg_unchanged = 207,
  end_unchanged = 836,
  unchanged_modified = 1088,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674307420
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=1728) at insdel.c:587
make_gap (nbytes_added=-1728) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$20 = {
  beg = 0x84f4ca0 ";; This buffer is for notes you don't want to save, and for Lis
p evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 208,
  z = 1044,
  gpt_byte = 208,
  z_byte = 1044,
  gap_size = 104,
  modiff = 1088,
  beg_unchanged = 1147,
  end_unchanged = 836,
  unchanged_modified = 1088,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674307420
}
(gdb)

Breakpoint 3, make_gap_smaller (nbytes_removed=1748) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$21 = {
  beg = 0x84d0870 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1170,
  z = 1274,
  gpt_byte = 1170,
  z_byte = 1274,
  gap_size = 1875,
  modiff = 1318,
  save_modiff = 0,
  overlay_modiff = 2,
  beg_unchanged = 1169,
  end_unchanged = 104,
  unchanged_modified = 1318,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674306720
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=1748) at insdel.c:587
make_gap (nbytes_added=-1748) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$22 = {
  beg = 0x84d0870 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1170,
  z = 1274,
  gpt_byte = 1170,
  z_byte = 1274,
  gap_size = 127,
  modiff = 1318,
  save_modiff = 0,
  overlay_modiff = 2,
  beg_unchanged = 1400,
  end_unchanged = 104,
  unchanged_modified = 1318,
  overlay_unchanged_modified = 2,
  intervals = 0x0,
  markers = 674306720
}
(gdb)  


If I try an explicit garbage collection, the following behaviour
is seen:
 
Breakpoint 3, make_gap_smaller (nbytes_removed=983) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$26 = {
  beg = 0x84e44c0 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1344,
  z = 4019,
  gpt_byte = 1344,
  z_byte = 4019,
  gap_size = 1384,
  modiff = 4063,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 1343,
  end_unchanged = 2675,
  unchanged_modified = 4063,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675045032
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=983) at insdel.c:587
make_gap (nbytes_added=-983) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$27 = {
  beg = 0x84e44c0 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 1344,
  z = 4019,
  gpt_byte = 1344,
  z_byte = 4019,
  gap_size = 401,
  modiff = 4063,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 4419,
  end_unchanged = 2675,
  unchanged_modified = 4063,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675045032
}
(gdb)          


 
Breakpoint 3, make_gap_smaller (nbytes_removed=1322) at insdel.c:587
587       if (GAP_SIZE - nbytes_removed < 20)
(gdb) p *current_buffer->text
$29 = {
  beg = 0x84b78d8 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 887,
  z = 4636,
  gpt_byte = 887,
  z_byte = 4636,
  gap_size = 1785,
  modiff = 4680,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 886,
  end_unchanged = 3749,
  unchanged_modified = 4680,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675044292
}
(gdb) fin
Run till exit from #0  make_gap_smaller (nbytes_removed=1322) at insdel.c:587
make_gap (nbytes_added=-1322) at insdel.c:639
639     }
(gdb) p *current_buffer->text
$30 = {
  beg = 0x84b78d8 ";; This buffer is for notes you don't want to save, and for Lisp evaluation.\n;; If you want to create a file, visit that file with C-x C-f,\n;;
then enter the text in that file's own buffer.\nnnnnnnnnnn"...,
  gpt = 887,
  z = 4636,
  gpt_byte = 887,
  z_byte = 4636,
  gap_size = 463,
  modiff = 4680,
  save_modiff = 0,
  overlay_modiff = 6,
  beg_unchanged = 5098,
  end_unchanged = 3749,
  unchanged_modified = 4680,
  overlay_unchanged_modified = 6,
  intervals = 0x0,
  markers = 675044292
}
(gdb) 


I have tried hard to understand what's going on, but maybe someone
else is able to see what might be wrong here...

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


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Gerd Moellmann]

storm@cua.dk (Kim F. Storm) writes:


[...]

> I have now tracked the problem down to the following change:
> 
> 2001-12-11  Andrew Innes  <andrewi@gnu.org>
> 
> 	* 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.

From the top of my head, I'm not aware of code in redisplay using
pointers into buffers instead of buffer char/byte positions, i.e., int
offsets from the buffer start.  So, I guess the only way to find out
if that is the problem, and if so where it is, is to look at the stack
backtraces when stopping in the debugger in make_gap_smaller during
redisplay and to check all the relevant functions from the backtrace
if they somehow keep a pointer into a buffer around the call to
something that can GC.

(A quick fix would be to disable the shrinking of the gap for GCs
during redisplay, which could be done by checking the value of the
variable redisplaying_p.)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Kim F. Storm]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> 
> [...]
> 
> > I have now tracked the problem down to the following change:
> > 
> > 2001-12-11  Andrew Innes  <andrewi@gnu.org>
> > 
> > 	* 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 <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Richard Stallman]

    > While typing in some text in a buffer, emacs suddenly decides to
    > insert a new line instead of the character I typed.  But if I do C-l,
    > there is only one line, and the character I typed magically reappears.

Actually it did not "insert a newline".  This evidence proves that.
The bug is in redisplay.

    If I comment out the call to make_gap_smaller in make_gap, the problem
    goes away!

This may be of some help, but the reliable way to track this down is
to step thru redisplay when the problem happens.  Anything else is
just guesswork.  There is a chance this "clue" will lead someone to
think of a possible cause, but if that doesn't happen, the reliable way
is likely to be the fastest way.

Don't waste your time staring at make_gap_smaller.  You know what
it does.  That's not where the problem is.

Here's what it makes me think of: is there anything in redisplay that
points to a buffer character by its address rather than by its
character number?  Anything that might live across the computation of
the mode line?

Is the problem reliably reproducible now?  If not, maybe you can make
that happen by having some function called from mode-line-format
execute (garbage-collect).



_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Richard Stallman]

Thank you for tracking this down.  Is the fix needed in RC?
I guess not if make_gap_smaller is not included in RC.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Richard Stallman]

    Don't waste your time staring at make_gap_smaller.  You know what
    it does.  That's not where the problem is.

I see I was wrong there.  What a surprise.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Thank you for tracking this down.  Is the fix needed in RC?
> I guess not if make_gap_smaller is not included in RC.

 make_gap_smaller is not present in RC.

++kfs


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel