GNU bug report logs -
#11199
24.0.95; killing right-to-left text at eob leads to inconsistent state
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11199 in the body.
You can then email your comments to 11199 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 02:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 08 Apr 2012 02:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Steps to reproduce:
1. emacs -Q
2. type the following text in the *scratch* buffer:
(progn
(delete-region (point) (point-max))
(insert (substring (get-language-info "Hebrew" 'sample-text) 7)))
3. move the cursor to the beginning of the next line of the above text.
4. C-x C-e
5. C-a
6. C-k
Result:
The Hebrew text is still shown, though it is internally killed.
Typing C-p after the last step does not move the cursor.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/home/mituharu/src/bzr/emacs/trunk/etc/DEBUG.
In GNU Emacs 24.0.95.1 (i686-pc-linux-gnu, GTK+ Version 2.24.6)
of 2012-04-07 on mituharu-MacBookAir
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
Configured using:
`configure '--enable-checking' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: ja_JP.UTF-8
value of $LC_CTYPE: ja_JP.UTF-8
value of $LC_MESSAGES: ja_JP.UTF-8
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ja_JP.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 07:37:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 08 Apr 2012 11:26:41 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
>
> Steps to reproduce:
>
> 1. emacs -Q
> 2. type the following text in the *scratch* buffer:
>
> (progn
> (delete-region (point) (point-max))
> (insert (substring (get-language-info "Hebrew" 'sample-text) 7)))
>
> 3. move the cursor to the beginning of the next line of the above text.
> 4. C-x C-e
> 5. C-a
> 6. C-k
>
> Result:
>
> The Hebrew text is still shown, though it is internally killed.
> Typing C-p after the last step does not move the cursor.
I cannot reproduce this with today's bzr, neither in the emacs-24
release branch nor with the trunk version. I cannot run a GUI session
with a GTK build on GNU/Linux where I'm typing this, but I tried GUI
and TTY sessions on MS-Windows and a TTY session on GNU/Linux, and
they all work correctly: the Hebrew text is killed and C-p works as
expected. (Btw, did you mean C-p or C-n?)
Can you try reproducing this in a clean build, or on another system?
Also, what happens on the system where you see the problem, if you
switch to another buffer and then back to *scratch*, so that it is
completely redrawn? does the killed text re-appear or not?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 18:30:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sun, 08 Apr 2012 11:26:41 +0900
>> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
>>
>> Steps to reproduce:
>>
>> 1. emacs -Q
>> 2. type the following text in the *scratch* buffer:
>>
>> (progn
>> (delete-region (point) (point-max))
>> (insert (substring (get-language-info "Hebrew" 'sample-text) 7)))
>>
>> 3. move the cursor to the beginning of the next line of the above text.
>> 4. C-x C-e
>> 5. C-a
>> 6. C-k
>>
>> Result:
>>
>> The Hebrew text is still shown, though it is internally killed.
>> Typing C-p after the last step does not move the cursor.
>
> I cannot reproduce this with today's bzr, neither in the emacs-24
> release branch nor with the trunk version. I cannot run a GUI session
> with a GTK build on GNU/Linux where I'm typing this, but I tried GUI
> and TTY sessions on MS-Windows and a TTY session on GNU/Linux, and
> they all work correctly: the Hebrew text is killed and C-p works as
> expected. (Btw, did you mean C-p or C-n?)
>
> Can you try reproducing this in a clean build, or on another system?
>
> Also, what happens on the system where you see the problem, if you
> switch to another buffer and then back to *scratch*, so that it is
> completely redrawn? does the killed text re-appear or not?
>
> Thanks.
I have assertions turned on and get an assertion failure. My setup is
as follows:
In GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, X toolkit)
of 2012-04-08 on maru
Bzr revision: 107799 eliz <at> gnu.org-20120408170903-4aew3wl3022qvr3e
Windowing system distributor `The X.Org Foundation', version 11.0.11104000
Configured using:
`configure '--without-gconf' '--without-gsettings'
'--without-toolkit-scroll-bars' '--with-x-toolkit=lucid' 'CFLAGS=-O0
-ggdb' '--enable-asserts' '--with-wide-int''
Build is from today's trunk. Here is the backtrace:
#0 abort () at emacs.c:390
#1 0x080779e7 in init_iterator (it=0xbfffa878, w=0x88e30d0, charpos=308,
bytepos=311, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2507
#2 0x080794bb in init_from_display_pos (it=0xbfffa878, w=0x88e30d0,
pos=0x8dccc58) at xdisp.c:2951
#3 0x08079810 in init_to_row_end (it=0xbfffa878, w=0x88e30d0, row=0x8dccbf0)
at xdisp.c:3054
#4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
#5 0x080a11fc in redisplay_window (window=-6917529027497545520,
just_this_one_p=1) at xdisp.c:15463
#6 0x0809a6e8 in redisplay_window_1 (window=-6917529027497545520)
at xdisp.c:13645
#7 0x0828b89f in internal_condition_case_1 (
bfun=0x809a6a2 <redisplay_window_1>, arg=-6917529027497545520,
handlers=-4611686018286052816, hfun=0x809a619 <redisplay_window_error>)
at eval.c:1553
#8 0x080996ee in redisplay_internal () at xdisp.c:13270
#9 0x08096754 in redisplay () at xdisp.c:12417
#10 0x081c9d36 in read_char (commandflag=1, nmaps=2, maps=0xbfffed60,
prev_event=4611686018568752328, used_mouse_menu=0xbfffeeac, end_time=0x0)
at keyboard.c:2448
#11 0x081dad15 in read_key_sequence (keybuf=0xbffff0f8, bufsize=30,
prompt=4611686018568752328, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9328
#12 0x081c6c32 in command_loop_1 () at keyboard.c:1449
#13 0x0828b710 in internal_condition_case (bfun=0x81c667f <command_loop_1>,
handlers=4611686018568799048, hfun=0x81c5c48 <cmd_error>) at eval.c:1515
#14 0x081c6255 in command_loop_2 (ignore=4611686018568752328)
at keyboard.c:1160
#15 0x0828af33 in internal_catch (tag=4611686018568792336,
func=0x81c621a <command_loop_2>, arg=4611686018568752328) at eval.c:1272
#16 0x081c61e0 in command_loop () at keyboard.c:1139
#17 0x081c56eb in recursive_edit_1 () at keyboard.c:759
#18 0x081c590f in Frecursive_edit () at keyboard.c:823
#19 0x081c34c1 in main (argc=2, argv=0xbffff964) at emacs.c:1711
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 18:35:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 11199 <at> debbugs.gnu.org (full text, mbox):
I should have mentioned the following. At the point of the assertion:
(gdb) p current_buffer->zv
$3 = 305
(gdb) p charpos
$4 = 308
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:07:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 11199 <at> debbugs.gnu.org
> Date: Sun, 08 Apr 2012 14:28:03 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Sun, 08 Apr 2012 11:26:41 +0900
> >> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> >>
> >> Steps to reproduce:
> >>
> >> 1. emacs -Q
> >> 2. type the following text in the *scratch* buffer:
> >>
> >> (progn
> >> (delete-region (point) (point-max))
> >> (insert (substring (get-language-info "Hebrew" 'sample-text) 7)))
> >>
> >> 3. move the cursor to the beginning of the next line of the above text.
> >> 4. C-x C-e
> >> 5. C-a
> >> 6. C-k
> >>
> >> Result:
> >>
> >> The Hebrew text is still shown, though it is internally killed.
> >> Typing C-p after the last step does not move the cursor.
> >
> > I cannot reproduce this with today's bzr, neither in the emacs-24
> > release branch nor with the trunk version. I cannot run a GUI session
> > with a GTK build on GNU/Linux where I'm typing this, but I tried GUI
> > and TTY sessions on MS-Windows and a TTY session on GNU/Linux, and
> > they all work correctly: the Hebrew text is killed and C-p works as
> > expected. (Btw, did you mean C-p or C-n?)
> >
> > Can you try reproducing this in a clean build, or on another system?
> >
> > Also, what happens on the system where you see the problem, if you
> > switch to another buffer and then back to *scratch*, so that it is
> > completely redrawn? does the killed text re-appear or not?
> >
> > Thanks.
>
> I have assertions turned on and get an assertion failure. My setup is
> as follows:
With the above recipe? Or with something different?
I have assertions turned on all the time, and I still cannot reproduce
this. Maybe I don't understand the recipe; can you describe exactly
where and how you type the Lisp code, and where you put the cursor
before "C-x C-e"?
In any case, please go to this frame:
#4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
and type:
(gdb) pgrowx last_unchanged_at_beg_row
(gdb) prowlims last_unchanged_at_beg_row
then post here everything printed by GDB. (These commands are
available only if you start GDB from the src directory; if not, type
"source /path/to/emacs/src/.gdbinit" before them.)
TIA
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:16:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 08 Apr 2012 23:03:07 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 11199 <at> debbugs.gnu.org
>
> > I have assertions turned on and get an assertion failure. My setup is
> > as follows:
>
> With the above recipe? Or with something different?
Also, when exactly does the assertion failure occur? when you type the
final C-k or earlier?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:18:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Michael Welsh Duggan <md5i <at> md5i.com>
>> Cc: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>, 11199 <at> debbugs.gnu.org
>> Date: Sun, 08 Apr 2012 14:28:03 -0400
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Date: Sun, 08 Apr 2012 11:26:41 +0900
>> >> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
>> >>
>> >> Steps to reproduce:
>> >>
>> >> 1. emacs -Q
>> >> 2. type the following text in the *scratch* buffer:
>> >>
>> >> (progn
>> >> (delete-region (point) (point-max))
>> >> (insert (substring (get-language-info "Hebrew" 'sample-text) 7)))
>> >>
>> >> 3. move the cursor to the beginning of the next line of the above text.
>> >> 4. C-x C-e
>> >> 5. C-a
>> >> 6. C-k
>> >>
>> >> Result:
>> >>
>> >> The Hebrew text is still shown, though it is internally killed.
>> >> Typing C-p after the last step does not move the cursor.
[...]
>> I have assertions turned on and get an assertion failure. My setup is
>> as follows:
>
> With the above recipe? Or with something different?
With exactly the above recipe.
> I have assertions turned on all the time, and I still cannot reproduce
> this. Maybe I don't understand the recipe; can you describe exactly
> where and how you type the Lisp code, and where you put the cursor
> before "C-x C-e"?
I typed in the list expression directly into the *scratch* buffer, then
hit RET in order to get to the beginning of the next line. (This is how
I interpreted step 3 above.) So, at the time I type C-x C-e, I am at
the beginning of the line below the line containing the word "insert".
> In any case, please go to this frame:
>
> #4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
>
> and type:
>
> (gdb) pgrowx last_unchanged_at_beg_row
> (gdb) prowlims last_unchanged_at_beg_row
(gdb) up
#2 0x080794bb in init_from_display_pos (it=0xbfffa878, w=0x88e30d0,
pos=0x8d6e6a8) at xdisp.c:2951
(gdb) up
#3 0x08079810 in init_to_row_end (it=0xbfffa878, w=0x88e30d0, row=0x8d6e640)
at xdisp.c:3054
(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
1 8: CHAR[ ] pos=238 blev=0,btyp=L w=8 a+d=12+3 MB
2 16: CHAR[(] pos=239 blev=0,btyp=L w=8 a+d=12+3 MB
3 24: CHAR[i] pos=240 blev=0,btyp=L w=8 a+d=12+3 MB
4 32: CHAR[n] pos=241 blev=0,btyp=L w=8 a+d=12+3 MB
5 40: CHAR[s] pos=242 blev=0,btyp=L w=8 a+d=12+3 MB
6 48: CHAR[e] pos=243 blev=0,btyp=L w=8 a+d=12+3 MB
7 56: CHAR[r] pos=244 blev=0,btyp=L w=8 a+d=12+3 MB
8 64: CHAR[t] pos=245 blev=0,btyp=L w=8 a+d=12+3 MB
9 72: CHAR[ ] pos=246 blev=0,btyp=L w=8 a+d=12+3 MB
10 80: CHAR[(] pos=247 blev=0,btyp=L w=8 a+d=12+3 MB
11 88: CHAR[s] pos=248 blev=0,btyp=L w=8 a+d=12+3 MB
12 96: CHAR[u] pos=249 blev=0,btyp=L w=8 a+d=12+3 MB
13 104: CHAR[b] pos=250 blev=0,btyp=L w=8 a+d=12+3 MB
14 112: CHAR[s] pos=251 blev=0,btyp=L w=8 a+d=12+3 MB
15 120: CHAR[t] pos=252 blev=0,btyp=L w=8 a+d=12+3 MB
16 128: CHAR[r] pos=253 blev=0,btyp=L w=8 a+d=12+3 MB
17 136: CHAR[i] pos=254 blev=0,btyp=L w=8 a+d=12+3 MB
18 144: CHAR[n] pos=255 blev=0,btyp=L w=8 a+d=12+3 MB
19 152: CHAR[g] pos=256 blev=0,btyp=L w=8 a+d=12+3 MB
20 160: CHAR[ ] pos=257 blev=0,btyp=L w=8 a+d=12+3 MB
21 168: CHAR[(] pos=258 blev=0,btyp=L w=8 a+d=12+3 MB
22 176: CHAR[g] pos=259 blev=0,btyp=L w=8 a+d=12+3 MB
23 184: CHAR[e] pos=260 blev=0,btyp=L w=8 a+d=12+3 MB
24 192: CHAR[t] pos=261 blev=0,btyp=L w=8 a+d=12+3 MB
25 200: CHAR[-] pos=262 blev=0,btyp=L w=8 a+d=12+3 MB
26 208: CHAR[l] pos=263 blev=0,btyp=L w=8 a+d=12+3 MB
27 216: CHAR[a] pos=264 blev=0,btyp=L w=8 a+d=12+3 MB
28 224: CHAR[n] pos=265 blev=0,btyp=L w=8 a+d=12+3 MB
29 232: CHAR[g] pos=266 blev=0,btyp=L w=8 a+d=12+3 MB
30 240: CHAR[u] pos=267 blev=0,btyp=L w=8 a+d=12+3 MB
31 248: CHAR[a] pos=268 blev=0,btyp=L w=8 a+d=12+3 MB
32 256: CHAR[g] pos=269 blev=0,btyp=L w=8 a+d=12+3 MB
33 264: CHAR[e] pos=270 blev=0,btyp=L w=8 a+d=12+3 MB
34 272: CHAR[-] pos=271 blev=0,btyp=L w=8 a+d=12+3 MB
35 280: CHAR[i] pos=272 blev=0,btyp=L w=8 a+d=12+3 MB
36 288: CHAR[n] pos=273 blev=0,btyp=L w=8 a+d=12+3 MB
37 296: CHAR[f] pos=274 blev=0,btyp=L w=8 a+d=12+3 MB
38 304: CHAR[o] pos=275 blev=0,btyp=L w=8 a+d=12+3 MB
39 312: CHAR[ ] pos=276 blev=0,btyp=L w=8 a+d=12+3 MB
40 320: CHAR["] pos=277 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
41 328: CHAR[H] pos=278 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
42 336: CHAR[e] pos=279 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
43 344: CHAR[b] pos=280 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
44 352: CHAR[r] pos=281 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
45 360: CHAR[e] pos=282 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
46 368: CHAR[w] pos=283 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
47 376: CHAR["] pos=284 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
48 384: CHAR[ ] pos=285 blev=0,btyp=L w=8 a+d=12+3 MB
49 392: CHAR['] pos=286 blev=0,btyp=L w=8 a+d=12+3 MB
50 400: CHAR[s] pos=287 blev=0,btyp=L w=8 a+d=12+3 MB
51 408: CHAR[a] pos=288 blev=0,btyp=L w=8 a+d=12+3 MB
52 416: CHAR[m] pos=289 blev=0,btyp=L w=8 a+d=12+3 MB
53 424: CHAR[p] pos=290 blev=0,btyp=L w=8 a+d=12+3 MB
54 432: CHAR[l] pos=291 blev=0,btyp=L w=8 a+d=12+3 MB
55 440: CHAR[e] pos=292 blev=0,btyp=L w=8 a+d=12+3 MB
56 448: CHAR[-] pos=293 blev=0,btyp=L w=8 a+d=12+3 MB
57 456: CHAR[t] pos=294 blev=0,btyp=L w=8 a+d=12+3 MB
58 464: CHAR[e] pos=295 blev=0,btyp=L w=8 a+d=12+3 MB
59 472: CHAR[x] pos=296 blev=0,btyp=L w=8 a+d=12+3 MB
60 480: CHAR[t] pos=297 blev=0,btyp=L w=8 a+d=12+3 MB
61 488: CHAR[)] pos=298 blev=0,btyp=L w=8 a+d=12+3 MB
62 496: CHAR[ ] pos=299 blev=0,btyp=L w=8 a+d=12+3 MB
63 504: CHAR[7] pos=300 blev=0,btyp=L w=8 a+d=12+3 MB
64 512: CHAR[)] pos=301 blev=0,btyp=L w=8 a+d=12+3 MB
65 520: CHAR[)] pos=302 blev=0,btyp=L w=8 a+d=12+3 MB
66 528: CHAR[)] pos=303 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)
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:21:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sun, 08 Apr 2012 23:03:07 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 11199 <at> debbugs.gnu.org
>>
>> > I have assertions turned on and get an assertion failure. My setup is
>> > as follows:
>>
>> With the above recipe? Or with something different?
>
> Also, when exactly does the assertion failure occur? when you type the
> final C-k or earlier?
When I type the C-k.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:24:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> 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
> 1 8: CHAR[ ] pos=238 blev=0,btyp=L w=8 a+d=12+3 MB
> 2 16: CHAR[(] pos=239 blev=0,btyp=L w=8 a+d=12+3 MB
> 3 24: CHAR[i] pos=240 blev=0,btyp=L w=8 a+d=12+3 MB
> 4 32: CHAR[n] pos=241 blev=0,btyp=L w=8 a+d=12+3 MB
> 5 40: CHAR[s] pos=242 blev=0,btyp=L w=8 a+d=12+3 MB
> 6 48: CHAR[e] pos=243 blev=0,btyp=L w=8 a+d=12+3 MB
> 7 56: CHAR[r] pos=244 blev=0,btyp=L w=8 a+d=12+3 MB
> 8 64: CHAR[t] pos=245 blev=0,btyp=L w=8 a+d=12+3 MB
> 9 72: CHAR[ ] pos=246 blev=0,btyp=L w=8 a+d=12+3 MB
> 10 80: CHAR[(] pos=247 blev=0,btyp=L w=8 a+d=12+3 MB
> 11 88: CHAR[s] pos=248 blev=0,btyp=L w=8 a+d=12+3 MB
> 12 96: CHAR[u] pos=249 blev=0,btyp=L w=8 a+d=12+3 MB
> 13 104: CHAR[b] pos=250 blev=0,btyp=L w=8 a+d=12+3 MB
> 14 112: CHAR[s] pos=251 blev=0,btyp=L w=8 a+d=12+3 MB
> 15 120: CHAR[t] pos=252 blev=0,btyp=L w=8 a+d=12+3 MB
> 16 128: CHAR[r] pos=253 blev=0,btyp=L w=8 a+d=12+3 MB
> 17 136: CHAR[i] pos=254 blev=0,btyp=L w=8 a+d=12+3 MB
> 18 144: CHAR[n] pos=255 blev=0,btyp=L w=8 a+d=12+3 MB
> 19 152: CHAR[g] pos=256 blev=0,btyp=L w=8 a+d=12+3 MB
> 20 160: CHAR[ ] pos=257 blev=0,btyp=L w=8 a+d=12+3 MB
> 21 168: CHAR[(] pos=258 blev=0,btyp=L w=8 a+d=12+3 MB
> 22 176: CHAR[g] pos=259 blev=0,btyp=L w=8 a+d=12+3 MB
> 23 184: CHAR[e] pos=260 blev=0,btyp=L w=8 a+d=12+3 MB
> 24 192: CHAR[t] pos=261 blev=0,btyp=L w=8 a+d=12+3 MB
> 25 200: CHAR[-] pos=262 blev=0,btyp=L w=8 a+d=12+3 MB
> 26 208: CHAR[l] pos=263 blev=0,btyp=L w=8 a+d=12+3 MB
> 27 216: CHAR[a] pos=264 blev=0,btyp=L w=8 a+d=12+3 MB
> 28 224: CHAR[n] pos=265 blev=0,btyp=L w=8 a+d=12+3 MB
> 29 232: CHAR[g] pos=266 blev=0,btyp=L w=8 a+d=12+3 MB
> 30 240: CHAR[u] pos=267 blev=0,btyp=L w=8 a+d=12+3 MB
> 31 248: CHAR[a] pos=268 blev=0,btyp=L w=8 a+d=12+3 MB
> 32 256: CHAR[g] pos=269 blev=0,btyp=L w=8 a+d=12+3 MB
> 33 264: CHAR[e] pos=270 blev=0,btyp=L w=8 a+d=12+3 MB
> 34 272: CHAR[-] pos=271 blev=0,btyp=L w=8 a+d=12+3 MB
> 35 280: CHAR[i] pos=272 blev=0,btyp=L w=8 a+d=12+3 MB
> 36 288: CHAR[n] pos=273 blev=0,btyp=L w=8 a+d=12+3 MB
> 37 296: CHAR[f] pos=274 blev=0,btyp=L w=8 a+d=12+3 MB
> 38 304: CHAR[o] pos=275 blev=0,btyp=L w=8 a+d=12+3 MB
> 39 312: CHAR[ ] pos=276 blev=0,btyp=L w=8 a+d=12+3 MB
> 40 320: CHAR["] pos=277 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 41 328: CHAR[H] pos=278 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 42 336: CHAR[e] pos=279 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 43 344: CHAR[b] pos=280 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 44 352: CHAR[r] pos=281 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 45 360: CHAR[e] pos=282 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 46 368: CHAR[w] pos=283 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 47 376: CHAR["] pos=284 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
> 48 384: CHAR[ ] pos=285 blev=0,btyp=L w=8 a+d=12+3 MB
> 49 392: CHAR['] pos=286 blev=0,btyp=L w=8 a+d=12+3 MB
> 50 400: CHAR[s] pos=287 blev=0,btyp=L w=8 a+d=12+3 MB
> 51 408: CHAR[a] pos=288 blev=0,btyp=L w=8 a+d=12+3 MB
> 52 416: CHAR[m] pos=289 blev=0,btyp=L w=8 a+d=12+3 MB
> 53 424: CHAR[p] pos=290 blev=0,btyp=L w=8 a+d=12+3 MB
> 54 432: CHAR[l] pos=291 blev=0,btyp=L w=8 a+d=12+3 MB
> 55 440: CHAR[e] pos=292 blev=0,btyp=L w=8 a+d=12+3 MB
> 56 448: CHAR[-] pos=293 blev=0,btyp=L w=8 a+d=12+3 MB
> 57 456: CHAR[t] pos=294 blev=0,btyp=L w=8 a+d=12+3 MB
> 58 464: CHAR[e] pos=295 blev=0,btyp=L w=8 a+d=12+3 MB
> 59 472: CHAR[x] pos=296 blev=0,btyp=L w=8 a+d=12+3 MB
> 60 480: CHAR[t] pos=297 blev=0,btyp=L w=8 a+d=12+3 MB
> 61 488: CHAR[)] pos=298 blev=0,btyp=L w=8 a+d=12+3 MB
> 62 496: CHAR[ ] pos=299 blev=0,btyp=L w=8 a+d=12+3 MB
> 63 504: CHAR[7] pos=300 blev=0,btyp=L w=8 a+d=12+3 MB
> 64 512: CHAR[)] pos=301 blev=0,btyp=L w=8 a+d=12+3 MB
> 65 520: CHAR[)] pos=302 blev=0,btyp=L w=8 a+d=12+3 MB
> 66 528: CHAR[)] pos=303 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:27:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Michael Welsh Duggan <md5i <at> md5i.com>
>> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> 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
>> 1 8: CHAR[ ] pos=238 blev=0,btyp=L w=8 a+d=12+3 MB
>> 2 16: CHAR[(] pos=239 blev=0,btyp=L w=8 a+d=12+3 MB
>> 3 24: CHAR[i] pos=240 blev=0,btyp=L w=8 a+d=12+3 MB
>> 4 32: CHAR[n] pos=241 blev=0,btyp=L w=8 a+d=12+3 MB
>> 5 40: CHAR[s] pos=242 blev=0,btyp=L w=8 a+d=12+3 MB
>> 6 48: CHAR[e] pos=243 blev=0,btyp=L w=8 a+d=12+3 MB
>> 7 56: CHAR[r] pos=244 blev=0,btyp=L w=8 a+d=12+3 MB
>> 8 64: CHAR[t] pos=245 blev=0,btyp=L w=8 a+d=12+3 MB
>> 9 72: CHAR[ ] pos=246 blev=0,btyp=L w=8 a+d=12+3 MB
>> 10 80: CHAR[(] pos=247 blev=0,btyp=L w=8 a+d=12+3 MB
>> 11 88: CHAR[s] pos=248 blev=0,btyp=L w=8 a+d=12+3 MB
>> 12 96: CHAR[u] pos=249 blev=0,btyp=L w=8 a+d=12+3 MB
>> 13 104: CHAR[b] pos=250 blev=0,btyp=L w=8 a+d=12+3 MB
>> 14 112: CHAR[s] pos=251 blev=0,btyp=L w=8 a+d=12+3 MB
>> 15 120: CHAR[t] pos=252 blev=0,btyp=L w=8 a+d=12+3 MB
>> 16 128: CHAR[r] pos=253 blev=0,btyp=L w=8 a+d=12+3 MB
>> 17 136: CHAR[i] pos=254 blev=0,btyp=L w=8 a+d=12+3 MB
>> 18 144: CHAR[n] pos=255 blev=0,btyp=L w=8 a+d=12+3 MB
>> 19 152: CHAR[g] pos=256 blev=0,btyp=L w=8 a+d=12+3 MB
>> 20 160: CHAR[ ] pos=257 blev=0,btyp=L w=8 a+d=12+3 MB
>> 21 168: CHAR[(] pos=258 blev=0,btyp=L w=8 a+d=12+3 MB
>> 22 176: CHAR[g] pos=259 blev=0,btyp=L w=8 a+d=12+3 MB
>> 23 184: CHAR[e] pos=260 blev=0,btyp=L w=8 a+d=12+3 MB
>> 24 192: CHAR[t] pos=261 blev=0,btyp=L w=8 a+d=12+3 MB
>> 25 200: CHAR[-] pos=262 blev=0,btyp=L w=8 a+d=12+3 MB
>> 26 208: CHAR[l] pos=263 blev=0,btyp=L w=8 a+d=12+3 MB
>> 27 216: CHAR[a] pos=264 blev=0,btyp=L w=8 a+d=12+3 MB
>> 28 224: CHAR[n] pos=265 blev=0,btyp=L w=8 a+d=12+3 MB
>> 29 232: CHAR[g] pos=266 blev=0,btyp=L w=8 a+d=12+3 MB
>> 30 240: CHAR[u] pos=267 blev=0,btyp=L w=8 a+d=12+3 MB
>> 31 248: CHAR[a] pos=268 blev=0,btyp=L w=8 a+d=12+3 MB
>> 32 256: CHAR[g] pos=269 blev=0,btyp=L w=8 a+d=12+3 MB
>> 33 264: CHAR[e] pos=270 blev=0,btyp=L w=8 a+d=12+3 MB
>> 34 272: CHAR[-] pos=271 blev=0,btyp=L w=8 a+d=12+3 MB
>> 35 280: CHAR[i] pos=272 blev=0,btyp=L w=8 a+d=12+3 MB
>> 36 288: CHAR[n] pos=273 blev=0,btyp=L w=8 a+d=12+3 MB
>> 37 296: CHAR[f] pos=274 blev=0,btyp=L w=8 a+d=12+3 MB
>> 38 304: CHAR[o] pos=275 blev=0,btyp=L w=8 a+d=12+3 MB
>> 39 312: CHAR[ ] pos=276 blev=0,btyp=L w=8 a+d=12+3 MB
>> 40 320: CHAR["] pos=277 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 41 328: CHAR[H] pos=278 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 42 336: CHAR[e] pos=279 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 43 344: CHAR[b] pos=280 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 44 352: CHAR[r] pos=281 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 45 360: CHAR[e] pos=282 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 46 368: CHAR[w] pos=283 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 47 376: CHAR["] pos=284 blev=0,btyp=L w=8 a+d=12+3 face=15 MB
>> 48 384: CHAR[ ] pos=285 blev=0,btyp=L w=8 a+d=12+3 MB
>> 49 392: CHAR['] pos=286 blev=0,btyp=L w=8 a+d=12+3 MB
>> 50 400: CHAR[s] pos=287 blev=0,btyp=L w=8 a+d=12+3 MB
>> 51 408: CHAR[a] pos=288 blev=0,btyp=L w=8 a+d=12+3 MB
>> 52 416: CHAR[m] pos=289 blev=0,btyp=L w=8 a+d=12+3 MB
>> 53 424: CHAR[p] pos=290 blev=0,btyp=L w=8 a+d=12+3 MB
>> 54 432: CHAR[l] pos=291 blev=0,btyp=L w=8 a+d=12+3 MB
>> 55 440: CHAR[e] pos=292 blev=0,btyp=L w=8 a+d=12+3 MB
>> 56 448: CHAR[-] pos=293 blev=0,btyp=L w=8 a+d=12+3 MB
>> 57 456: CHAR[t] pos=294 blev=0,btyp=L w=8 a+d=12+3 MB
>> 58 464: CHAR[e] pos=295 blev=0,btyp=L w=8 a+d=12+3 MB
>> 59 472: CHAR[x] pos=296 blev=0,btyp=L w=8 a+d=12+3 MB
>> 60 480: CHAR[t] pos=297 blev=0,btyp=L w=8 a+d=12+3 MB
>> 61 488: CHAR[)] pos=298 blev=0,btyp=L w=8 a+d=12+3 MB
>> 62 496: CHAR[ ] pos=299 blev=0,btyp=L w=8 a+d=12+3 MB
>> 63 504: CHAR[7] pos=300 blev=0,btyp=L w=8 a+d=12+3 MB
>> 64 512: CHAR[)] pos=301 blev=0,btyp=L w=8 a+d=12+3 MB
>> 65 520: CHAR[)] pos=302 blev=0,btyp=L w=8 a+d=12+3 MB
>> 66 528: CHAR[)] pos=303 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
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
}
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:41:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> debbugs.gnu.org
> Date: Sun, 08 Apr 2012 16:25:46 -0400
>
> >> (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
> >> ...
> >> 66 528: CHAR[)] pos=303 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
> },
That's the problem: the end position does not correspond to the actual
buffer positions of the characters in the glyph row (which are 237 to
303). But how could that happen?.. And why doesn't it happen to me?
I cannot even make init_to_row_end be called when I type C-k.
Btw, if you set bidi-display-reordering nil in *scratch* before typing
the recipe, does the crash still happen?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:51:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Michael Welsh Duggan <md5i <at> md5i.com>
>> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> debbugs.gnu.org
>> Date: Sun, 08 Apr 2012 16:25:46 -0400
>>
>> >> (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
>> >> ...
>> >> 66 528: CHAR[)] pos=303 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
>> },
>
> That's the problem: the end position does not correspond to the actual
> buffer positions of the characters in the glyph row (which are 237 to
> 303). But how could that happen?.. And why doesn't it happen to me?
> I cannot even make init_to_row_end be called when I type C-k.
>
> Btw, if you set bidi-display-reordering nil in *scratch* before typing
> the recipe, does the crash still happen?
It does not. If you need me to poke around just point me in the right
direction.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 20:52:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 08 Apr 2012 23:37:22 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 11199 <at> debbugs.gnu.org
>
> > (gdb) p row->end
> > $8 = {
> > pos = {
> > charpos = 309,
> > bytepos = 313
> > },
Btw, if row->end is at character position 309, how come in this frame:
#1 0x080779e7 in init_iterator (it=0xbfffa878, w=0x88e30d0, charpos=308,
bytepos=311, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2507
init_iterator is called with character position 308? What is `pos' in
this frame #2:
#2 0x080794bb in init_from_display_pos (it=0xbfffa878, w=0x88e30d0,
pos=0x8dccc58) at xdisp.c:2951
That is,
(gdb) frame 2
(gdb) p *pos
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 21:03:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Sun, 08 Apr 2012 23:37:22 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 11199 <at> debbugs.gnu.org
>>
>> > (gdb) p row->end
>> > $8 = {
>> > pos = {
>> > charpos = 309,
>> > bytepos = 313
>> > },
>
> Btw, if row->end is at character position 309, how come in this frame:
>
> #1 0x080779e7 in init_iterator (it=0xbfffa878, w=0x88e30d0, charpos=308,
> bytepos=311, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2507
>
> init_iterator is called with character position 308? What is `pos' in
> this frame #2:
>
> #2 0x080794bb in init_from_display_pos (it=0xbfffa878, w=0x88e30d0,
> pos=0x8dccc58) at xdisp.c:2951
>
> That is,
>
> (gdb) frame 2
> (gdb) p *pos
I had to recreate the error, so to make sure the numbers were
consistent, I re-printed out these positions from different frames:
Breakpoint 1, abort () at emacs.c:390
(gdb) up
#1 0x080779e7 in init_iterator (it=0xbfffa878, w=0x88e30d0, charpos=308,
bytepos=311, row=0x0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2507
(gdb) up
#2 0x080794bb in init_from_display_pos (it=0xbfffa878, w=0x88e30d0,
pos=0x8d60df0) at xdisp.c:2951
(gdb) p *pos
$9 = {
pos = {
charpos = 308,
bytepos = 311
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
}
(gdb) up
#3 0x08079810 in init_to_row_end (it=0xbfffa878, w=0x88e30d0, row=0x8d60d88)
at xdisp.c:3054
(gdb) p row->end
$10 = {
pos = {
charpos = 308,
bytepos = 311
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
}
(gdb) up
#4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
(gdb) p row->end
$11 = {
pos = {
charpos = 309,
bytepos = 313
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
}
(gdb)
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 21:11:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> debbugs.gnu.org
> Date: Sun, 08 Apr 2012 16:49:14 -0400
>
> > Btw, if you set bidi-display-reordering nil in *scratch* before typing
> > the recipe, does the crash still happen?
>
> It does not. If you need me to poke around just point me in the right
> direction.
Well, it would help if you could find out how does row->end get out of
sync with row->maxpos, for this specific row. Both end and maxpos are
set near the end of display_line, around line 19480 of xdisp.c. They
are identical when bidi-display-reordering is turned off, but
different when it's on (because maxpos-1 gives the largest buffer
position of the characters in the row, while end-1 gives the buffer
position of the rightmost character on display). In this case, it
looks like row->end came from a totally different screen line, the one
that was killed by C-k. I wonder how could that happen and which code
is responsible. Perhaps some code tries to reuse existing rows, and
goofs.
One way to find out is to step through the code in display_line that
computes row->end and row->maxpos for the offending line, the one that
starts with " (insert", and then put a hardware watchpoint on the
'end' field of that glyph_row structure, and see when it triggers.
TIA
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 21:14:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: 11199 <at> debbugs.gnu.org
> Date: Sun, 08 Apr 2012 17:01:31 -0400
>
> (gdb) up
> #4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
> (gdb) p row->end
> $11 = {
> pos = {
> charpos = 309,
> bytepos = 313
> },
row->end is wrong here, please show last_unchanged_at_beg_row->end
instead.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Sun, 08 Apr 2012 21:19:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Michael Welsh Duggan <md5i <at> md5i.com>
>> Cc: 11199 <at> debbugs.gnu.org
>> Date: Sun, 08 Apr 2012 17:01:31 -0400
>>
>> (gdb) up
>> #4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
>> (gdb) p row->end
>> $11 = {
>> pos = {
>> charpos = 309,
>> bytepos = 313
>> },
>
> row->end is wrong here, please show last_unchanged_at_beg_row->end
> instead.
(gdb) p last_unchanged_at_beg_row->end
$12 = {
pos = {
charpos = 308,
bytepos = 311
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
}
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 06:28:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: 11199 <at> debbugs.gnu.org
> Date: Sun, 08 Apr 2012 17:17:37 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Michael Welsh Duggan <md5i <at> md5i.com>
> >> Cc: 11199 <at> debbugs.gnu.org
> >> Date: Sun, 08 Apr 2012 17:01:31 -0400
> >>
> >> (gdb) up
> >> #4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140
> >> (gdb) p row->end
> >> $11 = {
> >> pos = {
> >> charpos = 309,
> >> bytepos = 313
> >> },
> >
> > row->end is wrong here, please show last_unchanged_at_beg_row->end
> > instead.
>
> (gdb) p last_unchanged_at_beg_row->end
> $12 = {
> pos = {
> charpos = 308,
> bytepos = 311
> },
> overlay_string_index = -1,
> string_pos = {
> charpos = -1,
> bytepos = -1
> },
> dpvec_index = -1
> }
Thanks, this is consistent with the other frames; no mystery here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 08:23:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 11199 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 09 Apr 2012 00:07:42 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> Well, it would help if you could find out how does row->end get out
> of sync with row->maxpos, for this specific row. Both end and
> maxpos are set near the end of display_line, around line 19480 of
> xdisp.c. They are identical when bidi-display-reordering is turned
> off, but different when it's on (because maxpos-1 gives the largest
> buffer position of the characters in the row, while end-1 gives the
> buffer position of the rightmost character on display). In this
> case, it looks like row->end came from a totally different screen
> line, the one that was killed by C-k. I wonder how could that
> happen and which code is responsible. Perhaps some code tries to
> reuse existing rows, and goofs.
It seems that row->end gets "out of sync" much earlier than C-k,
actually just after C-x C-e in Step 4 in the original recipe. It is
set at the part you mentioned above in display_line:
19473 row->end = it->current;
and it->current has been updated by
19379 /* Consume the line end. This skips over invisible lines. */
19380 set_iterator_to_next (it, 1);
Maybe set_iterator_to_next has skipped too much, or another value
should be set to row->end if the subsequent row starts with some
right-to-left text?
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 09:14:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> debbugs.gnu.org
> Date: Sun, 08 Apr 2012 16:25:46 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Michael Welsh Duggan <md5i <at> md5i.com>
> >> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 09:36:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 09 Apr 2012 17:21:51 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: Michael Welsh Duggan <md5i <at> md5i.com>,
> 11199 <at> debbugs.gnu.org
>
> It seems that row->end gets "out of sync" much earlier than C-k,
> actually just after C-x C-e in Step 4 in the original recipe.
Yes, that matches my observations, see my last mail today.
> It is
> set at the part you mentioned above in display_line:
>
> 19473 row->end = it->current;
>
> and it->current has been updated by
>
> 19379 /* Consume the line end. This skips over invisible lines. */
> 19380 set_iterator_to_next (it, 1);
>
> Maybe set_iterator_to_next has skipped too much
Looks like it. Can you trace through set_iterator_to_next and its
subroutines, and see why it does so? One way of doing that is to put
a breakpoint in set_iterator_to_next conditioned by the value of point
(which is available as 'current_buffer->pt'). (If you don't condition
by value of point, you will hit the breakpoint too many times.)
> or another value should be set to row->end if the subsequent row
> starts with some right-to-left text?
No, row->end always preserves the last position information of the
display iterator, no matter if the text was or wasn't reordered. The
correct operation of the display engine when rendering the next line
depends on that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 09:50:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 11199 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 09 Apr 2012 12:10:09 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 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.
I guess this just comes from some white space difference introduced by
copy-and-paste.
> 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:
I get the same results on Mac OS X 10.7.3, X11 build.
> (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
(snip)
What is shown by
(gdb) p w->current_matrix->rows[6].end.pos
at this stage? I get
$7 = {
charpos = 308,
bytepos = 311
}
and it looks "out of sync" because edges=(237,305) for the 6th row.
I hope this is also reproducible at your side.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 10:21:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 09 Apr 2012 18:48:16 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: Michael Welsh Duggan <md5i <at> md5i.com>,
> 11199 <at> debbugs.gnu.org
>
> > (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
> (snip)
>
> What is shown by
>
> (gdb) p w->current_matrix->rows[6].end.pos
>
> at this stage? I get
>
> $7 = {
> charpos = 308,
> bytepos = 311
> }
>
> and it looks "out of sync" because edges=(237,305) for the 6th row.
> I hope this is also reproducible at your side.
It is, thanks! I now have a lead for my debugging. Stay tuned.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 11:11:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 09 Apr 2012 13:17:33 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 11199 <at> debbugs.gnu.org
>
> > Date: Mon, 09 Apr 2012 18:48:16 +0900
> > From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> > Cc: Michael Welsh Duggan <md5i <at> md5i.com>,
> > 11199 <at> debbugs.gnu.org
> >
> > > (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
> > (snip)
> >
> > What is shown by
> >
> > (gdb) p w->current_matrix->rows[6].end.pos
> >
> > at this stage? I get
> >
> > $7 = {
> > charpos = 308,
> > bytepos = 311
> > }
> >
> > and it looks "out of sync" because edges=(237,305) for the 6th row.
> > I hope this is also reproducible at your side.
>
> It is, thanks! I now have a lead for my debugging. Stay tuned.
Does the patch below fixes the problem? It does not fix the root
cause, but should work around it well enough for the release branch.
I will install a better (but more risky) fix on the trunk.
(There was nothing wrong with the end.pos values above, as long as the
Hebrew text in the next line existed: end.pos gives the position of
the leftmost character on display in that line, which is not
necessarily the first character after the newline. The problem is
that init_to_row_end should not use row->end at all.)
=== modified file 'src/xdisp.c'
--- src/xdisp.c 2012-03-31 19:30:53 +0000
+++ src/xdisp.c 2012-04-09 10:58:59 +0000
@@ -17137,7 +17137,8 @@ try_window_id (struct window *w)
if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (last_unchanged_at_beg_row))
GIVE_UP (17);
- if (init_to_row_end (&it, w, last_unchanged_at_beg_row) == 0)
+ if (CHARPOS (last_unchanged_at_beg_row->end.pos) > ZV
+ || init_to_row_end (&it, w, last_unchanged_at_beg_row) == 0)
GIVE_UP (18);
start_pos = it.current.pos;
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 11:56:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 09 Apr 2012 14:07:43 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 11199 <at> debbugs.gnu.org
>
> Does the patch below fixes the problem? It does not fix the root
> cause, but should work around it well enough for the release branch.
> I will install a better (but more risky) fix on the trunk.
Actually, I found a better fix that should be safe for both branch and
trunk. Please try it, instead of the one I sent before.
> (There was nothing wrong with the end.pos values above, as long as the
> Hebrew text in the next line existed: end.pos gives the position of
> the leftmost character on display in that line, which is not
> necessarily the first character after the newline. The problem is
> that init_to_row_end should not use row->end at all.)
Strike that last sentence, init_to_row_end is doing its job correctly.
These issues were finalized almost 2 years ago, and I succeeded to
forget all the gory details of this complexity.
Here's the patch to try:
=== modified file 'src/xdisp.c'
--- src/xdisp.c 2012-03-31 19:30:53 +0000
+++ src/xdisp.c 2012-04-09 11:46:50 +0000
@@ -16602,7 +16602,15 @@ find_last_unchanged_at_beg_row (struct w
continued. */
&& !(MATRIX_ROW_END_CHARPOS (row) == first_changed_pos
&& (row->continued_p
- || row->exact_window_width_line_p)))
+ || row->exact_window_width_line_p))
+ /* If ROW->end is beyond ZV, then ROW->end is outdated and
+ needs to be recomputed, so don't consider this row as
+ unchanged. This happens when the last line was
+ bidi-reordered and was killed immediately before this
+ redisplay cycle. In that case, ROW->end stores the
+ buffer position of the first visual-order character of
+ the next row, which is now beyond ZV. */
+ && CHARPOS (row->end.pos) <= ZV)
row_found = row;
/* Stop if last visible row. */
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 12:20:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 11199 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Here's the patch to try:
>
> === modified file 'src/xdisp.c'
> --- src/xdisp.c 2012-03-31 19:30:53 +0000
> +++ src/xdisp.c 2012-04-09 11:46:50 +0000
> @@ -16602,7 +16602,15 @@ find_last_unchanged_at_beg_row (struct w
> continued. */
> && !(MATRIX_ROW_END_CHARPOS (row) == first_changed_pos
> && (row->continued_p
> - || row->exact_window_width_line_p)))
> + || row->exact_window_width_line_p))
> + /* If ROW->end is beyond ZV, then ROW->end is outdated and
> + needs to be recomputed, so don't consider this row as
> + unchanged. This happens when the last line was
> + bidi-reordered and was killed immediately before this
> + redisplay cycle. In that case, ROW->end stores the
> + buffer position of the first visual-order character of
> + the next row, which is now beyond ZV. */
> + && CHARPOS (row->end.pos) <= ZV)
> row_found = row;
>
> /* Stop if last visible row. */
>
I can verify that this patch keeps the original recipe from causing
Emacs to crash. Everything looks good for now.
--
Michael Welsh Duggan
(md5i <at> md5i.com)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 12:38:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 11199 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Cc: mituharu <at> math.s.chiba-u.ac.jp, 11199 <at> debbugs.gnu.org
> Date: Mon, 09 Apr 2012 08:18:10 -0400
>
> > === modified file 'src/xdisp.c'
> > --- src/xdisp.c 2012-03-31 19:30:53 +0000
> > +++ src/xdisp.c 2012-04-09 11:46:50 +0000
> > @@ -16602,7 +16602,15 @@ find_last_unchanged_at_beg_row (struct w
> > continued. */
> > && !(MATRIX_ROW_END_CHARPOS (row) == first_changed_pos
> > && (row->continued_p
> > - || row->exact_window_width_line_p)))
> > + || row->exact_window_width_line_p))
> > + /* If ROW->end is beyond ZV, then ROW->end is outdated and
> > + needs to be recomputed, so don't consider this row as
> > + unchanged. This happens when the last line was
> > + bidi-reordered and was killed immediately before this
> > + redisplay cycle. In that case, ROW->end stores the
> > + buffer position of the first visual-order character of
> > + the next row, which is now beyond ZV. */
> > + && CHARPOS (row->end.pos) <= ZV)
> > row_found = row;
> >
> > /* Stop if last visible row. */
> >
>
> I can verify that this patch keeps the original recipe from causing
> Emacs to crash. Everything looks good for now.
Thanks, I installed this as revision 107792 on the emacs-24 branch. I
will wait for Yamamoto-san to confirm that this fixes his problem as
well, before I close this bug.
Thank you both for your great help in solving this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#11199; Package
emacs.
(Mon, 09 Apr 2012 23:52:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 11199 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 09 Apr 2012 15:34:40 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> I can verify that this patch keeps the original recipe from causing
>> Emacs to crash. Everything looks good for now.
> Thanks, I installed this as revision 107792 on the emacs-24 branch.
> I will wait for Yamamoto-san to confirm that this fixes his problem
> as well, before I close this bug.
Yes, it also works for me. Many thanks.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Tue, 10 Apr 2012 06:31:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>:
bug acknowledged by developer.
(Tue, 10 Apr 2012 06:31:04 GMT)
Full text and
rfc822 format available.
Message #91 received at 11199-done <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 10 Apr 2012 08:50:01 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: Michael Welsh Duggan <md5i <at> md5i.com>,
> 11199 <at> debbugs.gnu.org
>
> >>>>> On Mon, 09 Apr 2012 15:34:40 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> I can verify that this patch keeps the original recipe from causing
> >> Emacs to crash. Everything looks good for now.
>
> > Thanks, I installed this as revision 107792 on the emacs-24 branch.
> > I will wait for Yamamoto-san to confirm that this fixes his problem
> > as well, before I close this bug.
>
> Yes, it also works for me. Many thanks.
Thanks, closing.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 08 May 2012 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.