bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Welsh Duggan <md5i@md5i.com>
> Cc: mituharu@math.s.chiba-u.ac.jp,  11199@debbugs.gnu.org
> Date: Sun, 08 Apr 2012 16:25:46 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Michael Welsh Duggan <md5i@md5i.com>
> >> Cc: mituharu@math.s.chiba-u.ac.jp,  11199@debbugs.gnu.org
> >> Date: Sun, 08 Apr 2012 16:16:29 -0400
> >> 
> >> (gdb) up
> >> #4  0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
> >> (gdb) pgrowx last_unchanged_at_beg_row
> >> TEXT: 68 glyphs
> >>   0    0: CHAR[ ] pos=237 blev=0,btyp=L w=8 a+d=12+3 MB
> >>  [...]
> >>  67  536: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 MB
> >> (gdb) prowlims last_unchanged_at_beg_row
> >> edges=(237,305),r2l=0,cont=0,trunc=(0,0),at_zv=0
> >> (gdb) 
> >
> > And what does the following produce in this frame?
> >
> >   (gdb) p row->end
> 
> (gdb) p row->end
> $8 = {
>   pos = {
>     charpos = 309, 
>     bytepos = 313
>   }, 

I cannot figure out where these two numbers, 309 and 313, come from.
If I repeat the recipe and look at the glyph matrix _before_ C-k,
there are no such buffer positions anywhere in sight there.  Which is
what I'd expect, since after "C-x C-e", the buffer has only 308
characters.  The fact that you see positions beyond that means that,
at some point, the buffer was larger than that by 4 more characters.
Can you figure out how this happened?

Also, please verify that you see the same buffer positions in the
glyph matrix as I do.  Here's a GDB session I used to this end:

  (gdb) break Fredraw_display
  Breakpoint 3 at 0x10947df: file dispnew.c, line 3188.
  (gdb) r -Q
  Starting program: D:\gnu\bzr\emacs\trunk\src/./oo/i386/emacs.exe -Q

Now repeat the recipe, up to and including the "C-x C-e" command.
After that, type "M-x redraw-display RET", and GDB will kick in.

  Breakpoint 3, Fredraw_display () at dispnew.c:3188
  3188      FOR_EACH_FRAME (tail, frame)

Then:

  (gdb) break set_cursor_from_row
  Breakpoint 4 at 0x1180953: file xdisp.c, line 13663.
  (gdb) c
  Continuing.

  Breakpoint 4, set_cursor_from_row (w=0x38eea00, row=0x3873400,
      matrix=0x3840b80, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663
  13663     struct glyph *glyph = row->glyphs[TEXT_AREA];
  (gdb) bt 6
  #0  set_cursor_from_row (w=0x38eea00, row=0x3873400, matrix=0x3840b80,
      delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663
  #1  0x011954e9 in display_line (it=0x82dcd0) at xdisp.c:19574
  #2  0x01189a65 in try_window (window=59697669, pos=..., flags=0)
      at xdisp.c:16013
  #3  0x01175146 in display_echo_area_1 (a1=59697664, a2=53667866, a3=0, a4=0)
      at xdisp.c:10035
  #4  0x01173ef2 in with_echo_area_buffer (w=0x38eea00, which=0,
      fn=0x1175052 <display_echo_area_1>, a1=59697664, a2=53667866, a3=0, a4=0)
      at xdisp.c:9820
  #5  0x01175021 in display_echo_area (w=0x38eea00) at xdisp.c:9996
  (More stack frames follow...)
  (gdb) c
  Continuing.

  Breakpoint 4, set_cursor_from_row (w=0x38eec00, row=0x39254b4,
      matrix=0x3840400, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663
  13663     struct glyph *glyph = row->glyphs[TEXT_AREA];
  (gdb) bt 6
  #0  set_cursor_from_row (w=0x38eec00, row=0x39254b4, matrix=0x3840400,
      delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663
  #1  0x011954e9 in display_line (it=0x82ca40) at xdisp.c:19574
  #2  0x01189a65 in try_window (window=59698181, pos=..., flags=1)
      at xdisp.c:16013
  #3  0x0118731d in redisplay_window (window=59698181, just_this_one_p=0)
      at xdisp.c:15538
  #4  0x01180908 in redisplay_window_0 (window=59698181) at xdisp.c:13637
  #5  0x01033d9b in internal_condition_case_1 (
      bfun=0x11808d6 <redisplay_window_0>, arg=59698181, handlers=53652222,
      hfun=0x11808b5 <redisplay_window_error>) at eval.c:1553
  (More stack frames follow...)

The first time the breakpoint in set_cursor_from_row breaks is not of
interest: as you see from the backtrace, Emacs is updating the echo
area, not the *scratch* buffer which we are interested in.  So I typed
"continue".  The second time it breaks _is_ of interest.  To make sure
this is our buffer, type:

  (gdb) pp w->buffer
  #<buffer *scratch*>

(If what you see at this point is not *scratch*, keep typing
"continue" until you hit the breakpoint when *scratch* is the current
buffer.)

Then:

  (gdb) until 13696
  set_cursor_from_row (w=0x38eec00, row=0x39254b4, matrix=0x3840400, delta=0,
      delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13696
  13696     if (row->displays_text_p)
  (gdb) pmtxrows w->current_matrix
  0: edges=(1,78),r2l=0,cont=0,trunc=(0,0),at_zv=0
  1: edges=(78,141),r2l=0,cont=0,trunc=(0,0),at_zv=0
  2: edges=(141,191),r2l=0,cont=0,trunc=(0,0),at_zv=0
  3: edges=(191,192),r2l=0,cont=0,trunc=(0,0),at_zv=0
  4: edges=(192,199),r2l=0,cont=0,trunc=(0,0),at_zv=0
  5: edges=(199,237),r2l=0,cont=0,trunc=(0,0),at_zv=0
  6: edges=(237,305),r2l=0,cont=0,trunc=(0,0),at_zv=0
  7: edges=(305,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  8: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  9: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  10: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  11: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  12: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  13: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  14: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  15: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  16: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  17: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  18: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  19: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  20: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  21: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  22: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  23: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  24: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  25: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  26: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  27: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  28: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  29: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  30: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  31: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  32: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1
  33: edges=(0,0),r2l=0,cont=0,trunc=(0,0),at_zv=0
  34: edges=(0,0),r2l=0,cont=0,trunc=(0,0),at_zv=0
  35: edges=(0,0),r2l=0,cont=0,trunc=(0,0),at_zv=0

pmtxrows shows all the glyph_row structures in the glyph matrix,
including the buffer positions covered by each glyph row (== screen
line).  The last position of a row should always be equal to the first
position of the next row (except when lines are reordered and
continued, which is not the case here).

As you see, the largest buffer position known to display engine at
this point is 309, and the last line 7 has its ends_at_zv_p flag set,
as I would expect.  Do you see exactly the same contents of
w->current_matrix, or do you see something different?

Thanks.