* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state
@ 2012-04-08 2:26 YAMAMOTO Mitsuharu
2012-04-08 7:33 ` Eli Zaretskii
0 siblings, 1 reply; 29+ messages in thread
From: YAMAMOTO Mitsuharu @ 2012-04-08 2:26 UTC (permalink / raw)
To: 11199
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@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
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 2:26 bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state YAMAMOTO Mitsuharu @ 2012-04-08 7:33 ` Eli Zaretskii 2012-04-08 18:28 ` Michael Welsh Duggan 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 7:33 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: 11199 > Date: Sun, 08 Apr 2012 11:26:41 +0900 > From: YAMAMOTO Mitsuharu <mituharu@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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 7:33 ` Eli Zaretskii @ 2012-04-08 18:28 ` Michael Welsh Duggan 2012-04-08 18:33 ` Michael Welsh Duggan 2012-04-08 20:03 ` Eli Zaretskii 0 siblings, 2 replies; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 18:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 Eli Zaretskii <eliz@gnu.org> writes: >> Date: Sun, 08 Apr 2012 11:26:41 +0900 >> From: YAMAMOTO Mitsuharu <mituharu@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@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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 18:28 ` Michael Welsh Duggan @ 2012-04-08 18:33 ` Michael Welsh Duggan 2012-04-08 20:03 ` Eli Zaretskii 1 sibling, 0 replies; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 18:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 18:28 ` Michael Welsh Duggan 2012-04-08 18:33 ` Michael Welsh Duggan @ 2012-04-08 20:03 ` Eli Zaretskii 2012-04-08 20:13 ` Eli Zaretskii 2012-04-08 20:16 ` Michael Welsh Duggan 1 sibling, 2 replies; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 20:03 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > From: Michael Welsh Duggan <md5i@md5i.com> > Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, 11199@debbugs.gnu.org > Date: Sun, 08 Apr 2012 14:28:03 -0400 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> Date: Sun, 08 Apr 2012 11:26:41 +0900 > >> From: YAMAMOTO Mitsuharu <mituharu@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:03 ` Eli Zaretskii @ 2012-04-08 20:13 ` Eli Zaretskii 2012-04-08 20:19 ` Michael Welsh Duggan 2012-04-08 20:16 ` Michael Welsh Duggan 1 sibling, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 20:13 UTC (permalink / raw) To: md5i; +Cc: 11199 > Date: Sun, 08 Apr 2012 23:03:07 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 11199@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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:13 ` Eli Zaretskii @ 2012-04-08 20:19 ` Michael Welsh Duggan 0 siblings, 0 replies; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 20:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 Eli Zaretskii <eliz@gnu.org> writes: >> Date: Sun, 08 Apr 2012 23:03:07 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 11199@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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:03 ` Eli Zaretskii 2012-04-08 20:13 ` Eli Zaretskii @ 2012-04-08 20:16 ` Michael Welsh Duggan 2012-04-08 20:20 ` Eli Zaretskii 1 sibling, 1 reply; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 20:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 Eli Zaretskii <eliz@gnu.org> writes: >> From: Michael Welsh Duggan <md5i@md5i.com> >> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, 11199@debbugs.gnu.org >> Date: Sun, 08 Apr 2012 14:28:03 -0400 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> >> Date: Sun, 08 Apr 2012 11:26:41 +0900 >> >> From: YAMAMOTO Mitsuharu <mituharu@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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:16 ` Michael Welsh Duggan @ 2012-04-08 20:20 ` Eli Zaretskii 2012-04-08 20:25 ` Michael Welsh Duggan 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 20:20 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > 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 > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:20 ` Eli Zaretskii @ 2012-04-08 20:25 ` Michael Welsh Duggan 2012-04-08 20:37 ` Eli Zaretskii 2012-04-09 9:10 ` Eli Zaretskii 0 siblings, 2 replies; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 20:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 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 >> 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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:25 ` Michael Welsh Duggan @ 2012-04-08 20:37 ` Eli Zaretskii 2012-04-08 20:48 ` Eli Zaretskii 2012-04-08 20:49 ` Michael Welsh Duggan 2012-04-09 9:10 ` Eli Zaretskii 1 sibling, 2 replies; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 20:37 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > 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 > > >> (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? ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:37 ` Eli Zaretskii @ 2012-04-08 20:48 ` Eli Zaretskii 2012-04-08 21:01 ` Michael Welsh Duggan 2012-04-08 20:49 ` Michael Welsh Duggan 1 sibling, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 20:48 UTC (permalink / raw) To: md5i, 11199 > Date: Sun, 08 Apr 2012 23:37:22 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 11199@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:48 ` Eli Zaretskii @ 2012-04-08 21:01 ` Michael Welsh Duggan 2012-04-08 21:10 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 21:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 Eli Zaretskii <eliz@gnu.org> writes: >> Date: Sun, 08 Apr 2012 23:37:22 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 11199@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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 21:01 ` Michael Welsh Duggan @ 2012-04-08 21:10 ` Eli Zaretskii 2012-04-08 21:17 ` Michael Welsh Duggan 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 21:10 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > From: Michael Welsh Duggan <md5i@md5i.com> > Cc: 11199@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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 21:10 ` Eli Zaretskii @ 2012-04-08 21:17 ` Michael Welsh Duggan 2012-04-09 6:24 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 21:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 Eli Zaretskii <eliz@gnu.org> writes: >> From: Michael Welsh Duggan <md5i@md5i.com> >> Cc: 11199@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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 21:17 ` Michael Welsh Duggan @ 2012-04-09 6:24 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2012-04-09 6:24 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > From: Michael Welsh Duggan <md5i@md5i.com> > Cc: 11199@debbugs.gnu.org > Date: Sun, 08 Apr 2012 17:17:37 -0400 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: Michael Welsh Duggan <md5i@md5i.com> > >> Cc: 11199@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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:37 ` Eli Zaretskii 2012-04-08 20:48 ` Eli Zaretskii @ 2012-04-08 20:49 ` Michael Welsh Duggan 2012-04-08 21:07 ` Eli Zaretskii 1 sibling, 1 reply; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-08 20:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 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: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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:49 ` Michael Welsh Duggan @ 2012-04-08 21:07 ` Eli Zaretskii 2012-04-09 8:21 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-08 21:07 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > 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: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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 21:07 ` Eli Zaretskii @ 2012-04-09 8:21 ` YAMAMOTO Mitsuharu 2012-04-09 9:32 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: YAMAMOTO Mitsuharu @ 2012-04-09 8:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 >>>>> On Mon, 09 Apr 2012 00:07:42 +0300, Eli Zaretskii <eliz@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@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 8:21 ` YAMAMOTO Mitsuharu @ 2012-04-09 9:32 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2012-04-09 9:32 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: 11199 > Date: Mon, 09 Apr 2012 17:21:51 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: Michael Welsh Duggan <md5i@md5i.com>, > 11199@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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-08 20:25 ` Michael Welsh Duggan 2012-04-08 20:37 ` Eli Zaretskii @ 2012-04-09 9:10 ` Eli Zaretskii 2012-04-09 9:48 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-09 9:10 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 9:10 ` Eli Zaretskii @ 2012-04-09 9:48 ` YAMAMOTO Mitsuharu 2012-04-09 10:17 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: YAMAMOTO Mitsuharu @ 2012-04-09 9:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 >>>>> On Mon, 09 Apr 2012 12:10:09 +0300, Eli Zaretskii <eliz@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@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 9:48 ` YAMAMOTO Mitsuharu @ 2012-04-09 10:17 ` Eli Zaretskii 2012-04-09 11:07 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-09 10:17 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: 11199 > Date: Mon, 09 Apr 2012 18:48:16 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: Michael Welsh Duggan <md5i@md5i.com>, > 11199@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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 10:17 ` Eli Zaretskii @ 2012-04-09 11:07 ` Eli Zaretskii 2012-04-09 11:52 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-09 11:07 UTC (permalink / raw) To: mituharu, Michael Welsh Duggan; +Cc: 11199 > Date: Mon, 09 Apr 2012 13:17:33 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 11199@debbugs.gnu.org > > > Date: Mon, 09 Apr 2012 18:48:16 +0900 > > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > > Cc: Michael Welsh Duggan <md5i@md5i.com>, > > 11199@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; ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 11:07 ` Eli Zaretskii @ 2012-04-09 11:52 ` Eli Zaretskii 2012-04-09 12:18 ` Michael Welsh Duggan 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-09 11:52 UTC (permalink / raw) To: mituharu, md5i; +Cc: 11199 > Date: Mon, 09 Apr 2012 14:07:43 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 11199@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. */ ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 11:52 ` Eli Zaretskii @ 2012-04-09 12:18 ` Michael Welsh Duggan 2012-04-09 12:34 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: Michael Welsh Duggan @ 2012-04-09 12:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 Eli Zaretskii <eliz@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@md5i.com) ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 12:18 ` Michael Welsh Duggan @ 2012-04-09 12:34 ` Eli Zaretskii 2012-04-09 23:50 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 29+ messages in thread From: Eli Zaretskii @ 2012-04-09 12:34 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: 11199 > From: Michael Welsh Duggan <md5i@md5i.com> > Cc: mituharu@math.s.chiba-u.ac.jp, 11199@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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 12:34 ` Eli Zaretskii @ 2012-04-09 23:50 ` YAMAMOTO Mitsuharu 2012-04-10 6:27 ` Eli Zaretskii 0 siblings, 1 reply; 29+ messages in thread From: YAMAMOTO Mitsuharu @ 2012-04-09 23:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 11199 >>>>> On Mon, 09 Apr 2012 15:34:40 +0300, Eli Zaretskii <eliz@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@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state 2012-04-09 23:50 ` YAMAMOTO Mitsuharu @ 2012-04-10 6:27 ` Eli Zaretskii 0 siblings, 0 replies; 29+ messages in thread From: Eli Zaretskii @ 2012-04-10 6:27 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: 11199-done > Date: Tue, 10 Apr 2012 08:50:01 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: Michael Welsh Duggan <md5i@md5i.com>, > 11199@debbugs.gnu.org > > >>>>> On Mon, 09 Apr 2012 15:34:40 +0300, Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2012-04-10 6:27 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-08 2:26 bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state YAMAMOTO Mitsuharu 2012-04-08 7:33 ` Eli Zaretskii 2012-04-08 18:28 ` Michael Welsh Duggan 2012-04-08 18:33 ` Michael Welsh Duggan 2012-04-08 20:03 ` Eli Zaretskii 2012-04-08 20:13 ` Eli Zaretskii 2012-04-08 20:19 ` Michael Welsh Duggan 2012-04-08 20:16 ` Michael Welsh Duggan 2012-04-08 20:20 ` Eli Zaretskii 2012-04-08 20:25 ` Michael Welsh Duggan 2012-04-08 20:37 ` Eli Zaretskii 2012-04-08 20:48 ` Eli Zaretskii 2012-04-08 21:01 ` Michael Welsh Duggan 2012-04-08 21:10 ` Eli Zaretskii 2012-04-08 21:17 ` Michael Welsh Duggan 2012-04-09 6:24 ` Eli Zaretskii 2012-04-08 20:49 ` Michael Welsh Duggan 2012-04-08 21:07 ` Eli Zaretskii 2012-04-09 8:21 ` YAMAMOTO Mitsuharu 2012-04-09 9:32 ` Eli Zaretskii 2012-04-09 9:10 ` Eli Zaretskii 2012-04-09 9:48 ` YAMAMOTO Mitsuharu 2012-04-09 10:17 ` Eli Zaretskii 2012-04-09 11:07 ` Eli Zaretskii 2012-04-09 11:52 ` Eli Zaretskii 2012-04-09 12:18 ` Michael Welsh Duggan 2012-04-09 12:34 ` Eli Zaretskii 2012-04-09 23:50 ` YAMAMOTO Mitsuharu 2012-04-10 6:27 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).