* bug#1070: Looping in redisplay due to font problem @ 2008-10-02 23:47 ` Chong Yidong 2008-10-03 1:24 ` bug#1071: " Kenichi Handa 2008-10-09 16:50 ` bug#1070: " Emacs bug Tracking System 0 siblings, 2 replies; 15+ messages in thread From: Chong Yidong @ 2008-10-02 23:47 UTC (permalink / raw) To: Kenichi Handa; +Cc: emacs-pretest-bug After the 2008-07-09 change to ftfont.c, Emacs can loop during redisplay under the following conditions: xrdb /dev/null emacs -Q fc-list.list [fc-list.list is attached] <PageDown> <PageDown> <PageDown> <PageDown> Emacs begins looping while in redisplay, while displaying the text "Corsivo" (the final letter "o" blinks rapidly). Strangely enough, I can't reproduce this if I substitute C-v for PageDown (?!??!). Also, the bug doesn't show up if there is an X resource Emacs.geometry already defined. The problem seems to have appeared for the first time during the checkin listed below. My tests indicate that the other files involved this checkin do not affect the problem. Could you see if you can reproduce this problem, and review the code changes to see if they may have caused it? Thanks! 2008-07-09 Kenichi Handa <handa@m17n.org> * ftfont.c (struct ftfont_info): New member index, delete member fc_charset_idx. Make the member order compatible with struct xftfont_info. (fc_charset_table): Change charset names to registry names. (ftfont_pattern_entity): Delete the args registry and fc_charset_idx. Change the value of :font-entity property to (FONTNAME . INDEX). Always set :registry property to `iso10646-1'. (struct ftfont_cache_data): New struct. (ftfont_lookup_cache): New arg for_face. (ftfont_get_fc_charset, ftfont_get_otf): New functions. (ftfont_driver): Set the member otf_capability. (ftfont_get_charset): Adjust it for the change of fc_charset_table. (OTF_TAG_SYM): New macro. (ftfont_spec_pattern): Delete the arg fc_charset_idx. Adjust it for the change of fc_charset_table. (ftfont_list): Adjust it for the change of ftfont_spec_pattern and ftfont_pattern_entity. Add FC_INDEX to objset. (ftfont_match): Adjust it for the change of ftfont_spec_pattern and ftfont_pattern_entity. (ftfont_open): Adjust it for the change of ftfont_lookup_cache, font_make_object, struct ftfont_info. (ftfont_has_char): Use ftfont_get_fc_charset. (ftfont_otf_features, ftfont_otf_capability): New functions. (ftfont_shape): Use ftfont_get_otf. (ftfont_text_extents): Fix initial setting of metrics. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1071: Looping in redisplay due to font problem 2008-10-02 23:47 ` bug#1070: Looping in redisplay due to font problem Chong Yidong @ 2008-10-03 1:24 ` Kenichi Handa 2008-10-03 16:18 ` bug#1076: " Chong Yidong 2008-10-09 16:50 ` bug#1071: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1070: " Emacs bug Tracking System 1 sibling, 2 replies; 15+ messages in thread From: Kenichi Handa @ 2008-10-03 1:24 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-pretest-bug In article <878wt6a7aq.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes: > After the 2008-07-09 change to ftfont.c, Emacs can loop during redisplay > under the following conditions: > xrdb /dev/null > emacs -Q fc-list.list [fc-list.list is attached] > <PageDown> > <PageDown> > <PageDown> > <PageDown> > Emacs begins looping while in redisplay, while displaying the text > "Corsivo" (the final letter "o" blinks rapidly). > Strangely enough, I can't reproduce this if I substitute C-v for > PageDown (?!??!). Also, the bug doesn't show up if there is an X > resource Emacs.geometry already defined. > The problem seems to have appeared for the first time during the checkin > listed below. My tests indicate that the other files involved this > checkin do not affect the problem. > Could you see if you can reproduce this problem, and review the code > changes to see if they may have caused it? Thanks! That's a very strange phenomenon. But, I can't reproduce it. When I hit PageDown four times, the top line is "Luxi Sans:style=Regular", and "Corsivo" appears on the 9th line (logically 8th line because of continuation). In my case, this font is selected for the default case: -bitstream-Bitstream Vera Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1 Which font is selected in your case? And, what does "Emacs begins looping while in redisplay" exactly mean? --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1076: Looping in redisplay due to font problem 2008-10-03 1:24 ` bug#1071: " Kenichi Handa @ 2008-10-03 16:18 ` Chong Yidong 2008-10-06 2:32 ` bug#1097: " Kenichi Handa 2008-10-09 16:50 ` bug#1076: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1071: " Emacs bug Tracking System 1 sibling, 2 replies; 15+ messages in thread From: Chong Yidong @ 2008-10-03 16:18 UTC (permalink / raw) To: Kenichi Handa; +Cc: emacs-pretest-bug Kenichi Handa <handa@m17n.org> writes: > That's a very strange phenomenon. But, I can't reproduce > it. When I hit PageDown four times, the top line is "Luxi > Sans:style=Regular", and "Corsivo" appears on the 9th line > (logically 8th line because of continuation). > > In my case, this font is selected for the default case: > > -bitstream-Bitstream Vera Sans > Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1 > > Which font is selected in your case? C-u C-x = gives -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1 > And, what does "Emacs begins looping while in redisplay" exactly mean? Emacs is unresponsive to any further input, and the character "o" in "Corsivo" flickers. Interrupting the loop in gdb gives the following backtrace. It seems to be stuck in an Xft function. #0 0x00007f54662e1433 in select () from /lib/libc.so.6 #1 0x00007f546403b2b6 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007f546403b8eb in ?? () from /usr/lib/libxcb.so.1 #3 0x00007f546403c050 in xcb_send_request () from /usr/lib/libxcb.so.1 #4 0x00007f5466e71f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 #5 0x00007f5466e72267 in ?? () from /usr/lib/libX11.so.6 #6 0x00007f54650be5a3 in XRenderFillRectangle () from /usr/lib/libXrender.so.1 #7 0x00007f5466c1f5b1 in XftDrawRect () from /usr/lib/libXft.so.2 #8 0x0000000000656080 in xftfont_draw (s=0x7fff725843b0, from=0, to=1, x=100, y=175, with_background=1) at xftfont.c:549 #9 0x00000000004e0268 in x_draw_glyph_string_foreground (s=0x7fff725843b0) at xterm.c:1316 #10 0x00000000004e374c in x_draw_glyph_string (s=0x7fff725843b0) at xterm.c:2708 #11 0x00000000004616f1 in draw_glyphs (w=0x17ec430, x=110, row=0x1f49b20, area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504 #12 0x0000000000466ec1 in x_write_glyphs (start=0x145f748, len=1) at xdisp.c:21913 #13 0x0000000000418fa4 in update_text_area (w=0x17ec430, vpos=8) at dispnew.c:4584 ... ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1097: Looping in redisplay due to font problem 2008-10-03 16:18 ` bug#1076: " Chong Yidong @ 2008-10-06 2:32 ` Kenichi Handa 2008-10-06 16:37 ` bug#1101: " Chong Yidong 2008-10-09 16:50 ` bug#1097: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1076: " Emacs bug Tracking System 1 sibling, 2 replies; 15+ messages in thread From: Kenichi Handa @ 2008-10-06 2:32 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-pretest-bug In article <87vdw91wl1.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes: > > And, what does "Emacs begins looping while in redisplay" exactly mean? > Emacs is unresponsive to any further input, and the character "o" in > "Corsivo" flickers. Interrupting the loop in gdb gives the following > backtrace. It seems to be stuck in an Xft function. > #0 0x00007f54662e1433 in select () from /lib/libc.so.6 > #1 0x00007f546403b2b6 in ?? () from /usr/lib/libxcb.so.1 > #2 0x00007f546403b8eb in ?? () from /usr/lib/libxcb.so.1 > #3 0x00007f546403c050 in xcb_send_request () from /usr/lib/libxcb.so.1 > #4 0x00007f5466e71f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 > #5 0x00007f5466e72267 in ?? () from /usr/lib/libX11.so.6 > #6 0x00007f54650be5a3 in XRenderFillRectangle () from /usr/lib/libXrender.so.1 > #7 0x00007f5466c1f5b1 in XftDrawRect () from /usr/lib/libXft.so.2 > #8 0x0000000000656080 in xftfont_draw (s=0x7fff725843b0, from=0, to=1, x=100, Does Emacs always stop at that place when you repeat "cont" and "stop"? --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1101: Looping in redisplay due to font problem 2008-10-06 2:32 ` bug#1097: " Kenichi Handa @ 2008-10-06 16:37 ` Chong Yidong 2008-10-07 11:26 ` bug#1105: " Kenichi Handa 2008-10-09 16:50 ` bug#1101: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1097: " Emacs bug Tracking System 1 sibling, 2 replies; 15+ messages in thread From: Chong Yidong @ 2008-10-06 16:37 UTC (permalink / raw) To: Kenichi Handa; +Cc: emacs-pretest-bug Kenichi Handa <handa@m17n.org> writes: >> #0 0x00007f54662e1433 in select () from /lib/libc.so.6 >> #1 0x00007f546403b2b6 in ?? () from /usr/lib/libxcb.so.1 >> #2 0x00007f546403b8eb in ?? () from /usr/lib/libxcb.so.1 >> #3 0x00007f546403c050 in xcb_send_request () from /usr/lib/libxcb.so.1 >> #4 0x00007f5466e71f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 >> #5 0x00007f5466e72267 in ?? () from /usr/lib/libX11.so.6 >> #6 0x00007f54650be5a3 in XRenderFillRectangle () from /usr/lib/libXrender.so.1 > > Does Emacs always stop at that place when you repeat "cont" > and "stop"? Yes, it always seems to stop at this place. Here's `bt full' and a debugging session. I don't see anything wrong OTOH, and am unsure about what to look for. Stepping forward in gdb doesn't work because the program is stopped inside `select'. Any suggestions? #0 0x00007f6dd0fe5433 in select () from /lib/libc.so.6 #1 0x00007f6dcf0422b6 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007f6dcf0428eb in ?? () from /usr/lib/libxcb.so.1 #3 0x00007f6dcf043050 in xcb_send_request () from /usr/lib/libxcb.so.1 #4 0x00007f6dd1943f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 #5 0x00007f6dd1944267 in ?? () from /usr/lib/libX11.so.6 #6 0x00007f6dd19370bd in XSetClipMask () from /usr/lib/libX11.so.6 #7 0x00000000004e426d in x_draw_glyph_string (s=0x7fffdd7a95e0) at xterm.c:2883 relief_drawn_p = 0 #8 0x00000000004617cc in draw_glyphs (w=0x1cd5ad0, x=72, row=0x1f727d0, area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504 head = (struct glyph_string *) 0x7fffdd7a95e0 tail = (struct glyph_string *) 0x7fffdd7a95e0 s = (struct glyph_string *) 0x7fffdd7a95e0 clip_head = (struct glyph_string *) 0x0 clip_tail = (struct glyph_string *) 0x0 i = 8 j = -579167284 x_reached = 72 last_x = 648 area_left = 8 f = (struct frame *) 0x19a52b0 #9 0x0000000000466f9c in x_write_glyphs (start=0x13de968, len=1) at xdisp.c:21913 x = 0 hpos = 7 #10 0x0000000000418fe2 in update_text_area (w=0x1cd5ad0, vpos=8) at dispnew.c:4585 start_x = 56 start_hpos = 7 start = (struct glyph *) 0x13de968 current_x = 64 skip_first_p = 0 can_skip_p = 1 stop = 33 i = 8 desired_glyph = (struct glyph *) 0x13de990 overlapping_glyphs_p = 1 desired_stop_pos = 62 x = 64 current_glyph = (struct glyph *) 0x1f8d8e0 current_row = (struct glyph_row *) 0xf63610 desired_row = (struct glyph_row *) 0x1f727d0 rif = (struct redisplay_interface *) 0x8a46c0 changed_p = 1 (gdb) f 8 #8 0x0000000000656170 in xftfont_draw (s=0x7fff461d8010, from=0, to=1, x=64, y=149, with_background=1) at xftfont.c:549 549 XftDrawRect (xft_draw, &bg, (gdb) p s $1 = (struct glyph_string *) 0x7fff461d8010 (gdb) p *s $2 = { x = 64, y = 136, ybase = 149, width = 8, background_width = 8, height = 17, left_overhang = 0, right_overhang = 0, f = 0x19a52b0, w = 0x1cd5ad0, display = 0xcb8790, window = 54526142, row = 0x1f6f7f0, area = TEXT_AREA, char2b = 0x7fff461d7ff0, nchars = 1, hl = DRAW_NORMAL_TEXT, face = 0x13cdae0, font = 0x1c04810, cmp = 0x0, cmp_id = 0, cmp_from = 0, cmp_to = 0, extends_to_end_of_line_p = 0, background_filled_p = 0, two_byte_p = 0, font_not_found_p = 0, stippled_p = 0, for_overlaps = 0, padding_p = 0, gc = 0xfbbf00, first_glyph = 0x13de968, img = 0x0, slice = { x = 0, y = 0, width = 0, height = 0 }, clip_head = 0x0, clip_tail = 0x0, clip = {{ x = 8, y = 136, width = 640, height = 17 }, { x = 0, y = 0, width = 0, height = 0 }}, num_clips = 1, underline_position = 0, underline_thickness = 0, next = 0x0, prev = 0x0 } (gdb) p *(s->font) $3 = { size = 4611686018429485074, next = 0x1c121e0, props = {12109345, 21852401, 18521457, 11665121, 12097873, 205440, 205056, 205312, 104, 11665121, 800, 0, 12327557, 11665121, 31929283, 31929251, 31929347, 18521505}, max_width = 0, pixel_size = 13, height = 17, space_width = 8, average_width = 8, min_width = 8, ascent = 13, descent = 4, underline_thickness = 0, underline_position = 0, vertical_centering = 0, encoding_type = 0 '\0', baseline_offset = 0, relative_compose = 0, default_ascent = 0, font_encoder = 0x1c04aa0, driver = 0xb16da0, encoding_charset = -1, repertory_charset = -1 } ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1105: Looping in redisplay due to font problem 2008-10-06 16:37 ` bug#1101: " Chong Yidong @ 2008-10-07 11:26 ` Kenichi Handa 2008-10-07 16:14 ` bug#1070: " Chong Yidong 2008-10-09 16:50 ` bug#1105: marked as done (Looping in redisplay due to font problem) Emacs bug Tracking System 2008-10-09 16:50 ` bug#1101: " Emacs bug Tracking System 1 sibling, 2 replies; 15+ messages in thread From: Kenichi Handa @ 2008-10-07 11:26 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-pretest-bug In article <87y711r87e.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes: > Yes, it always seems to stop at this place. Here's `bt full' and a > debugging session. I don't see anything wrong OTOH, and am unsure about > what to look for. Stepping forward in gdb doesn't work because the > program is stopped inside `select'. Any suggestions? > #0 0x00007f6dd0fe5433 in select () from /lib/libc.so.6 > #1 0x00007f6dcf0422b6 in ?? () from /usr/lib/libxcb.so.1 > #2 0x00007f6dcf0428eb in ?? () from /usr/lib/libxcb.so.1 > #3 0x00007f6dcf043050 in xcb_send_request () from /usr/lib/libxcb.so.1 > #4 0x00007f6dd1943f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 > #5 0x00007f6dd1944267 in ?? () from /usr/lib/libX11.so.6 > #6 0x00007f6dd19370bd in XSetClipMask () from /usr/lib/libX11.so.6 > #7 0x00000000004e426d in x_draw_glyph_string (s=0x7fffdd7a95e0) > at xterm.c:2883 > relief_drawn_p = 0 > #8 0x00000000004617cc in draw_glyphs (w=0x1cd5ad0, x=72, row=0x1f727d0, > area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) > at xdisp.c:20504 Please try to comment out all calls of XSetClipMask in x_draw_glyph_string, and check if Emacs loops in redisplay. --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1070: Looping in redisplay due to font problem 2008-10-07 11:26 ` bug#1105: " Kenichi Handa @ 2008-10-07 16:14 ` Chong Yidong 2008-10-08 1:16 ` Kenichi Handa 2008-10-09 16:50 ` bug#1105: marked as done (Looping in redisplay due to font problem) Emacs bug Tracking System 1 sibling, 1 reply; 15+ messages in thread From: Chong Yidong @ 2008-10-07 16:14 UTC (permalink / raw) To: Kenichi Handa; +Cc: 1070 > Please try to comment out all calls of XSetClipMask in > x_draw_glyph_string, and check if Emacs loops in redisplay. It still loops, though the backtrace is different now. Interrupting the loop several times, I see that it gets stuck in two places within xftfont_draw, at xftfont.c:561 and xftfont.c:549. Another clue: I can't reproduce this bug on my 32-bit laptop, so maybe it only shows up on 64-bit machines. #0 0x00007ffc618cf433 in select () from /lib/libc.so.6 ... #6 0x00007ffc60dd07ad in XRenderCompositeString8 () #7 0x00007ffc61fe1aa5 in XftGlyphRender () from /usr/lib/libXft.so.2 #8 0x00007ffc61fdbb1c in XftDrawGlyphs () from /usr/lib/libXft.so.2 #9 0x000000000065618f in xftfont_draw (s=0x7fff6e090ee0, from=0, to=1, x=64, y=149, with_background=1) at xftfont.c:561 f = (FRAME_PTR) 0x19a52b0 face = (struct face *) 0x18ee6b0 xftfont_info = (struct xftfont_info *) 0x1c04810 xftface_info = (struct xftface_info *) 0xfbc3e0 xft_draw = (XftDraw *) 0x18088d0 code = (FT_UInt *) 0x7fff6e090c80 fg = { pixel = 16113331, color = {red = 62965, green = 57054, blue = 46003, alpha = 65535}} bg = {pixel = 0, color = {red = 0, green = 0, blue = 0 alpha = 65535}} len = 1 i = 1 #10 0x00000000004e02f6 in x_draw_glyph_string_foreground (s=0x7fff6e090ee0) at xterm.c:1316 font = (struct font *) 0x1c04810 boff = 0 y = 149 i = 0 x = 64 #11 0x00000000004e374d in x_draw_glyph_string (s=0x7fffd1fa8de0) at xterm.c:2708 #12 0x00000000004617cc in draw_glyphs (w=0x1cd5ad0, x=72, row=0x1f6fb20, area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504 #13 0x0000000000466f9c in x_write_glyphs (start=0x1fc1688, len=1) at xdisp.c:21913 #14 0x0000000000418fe2 in update_text_area (w=0x1cd5ad0, vpos=8) at dispnew.c:4585 ... (gdb) f 9 #9 0x000000000065618f in xftfont_draw (s=0x7fff6e090ee0, from=0, to=1, x=64, y=149, with_background=1) at xftfont.c:561 561 XftDrawGlyphs (xft_draw, &fg, xftfont_info->xftfont, (gdb) p *(xftfont_info->xftfont) $1 = {ascent = 13, descent = 4, height = 15, max_advance_width = 8, charset = 0x7ffc65f0f498, pattern = 0x1647700} #0 0x00007f44c57e4433 in select () from /lib/libc.so.6 ... #7 0x00007f44c5ef05b1 in XftDrawRect () from /usr/lib/libXft.so.2 #8 0x000000000065601c in xftfont_draw (s=0x7fffd1fa8de0, from=0, to=1, x=64, y=149, with_background=1) at xftfont.c:549 f = (FRAME_PTR) 0x18a0180 face = (struct face *) 0x13cd8a0 xftfont_info = (struct xftfont_info *) 0x1c04810 xftface_info = (struct xftface_info *) 0xfb65c0 xft_draw = (XftDraw *) 0x16bcee0 code = (FT_UInt *) 0x7fffd1fa8b80 fg = { pixel = 16113331, color = { red = 62965, green = 57054, blue = 46003, alpha = 65535 } } bg = { pixel = 0, color = { red = 0, green = 0, blue = 0, alpha = 65535 } } len = 1 i = 8912904 #9 0x00000000004e02f6 in x_draw_glyph_string_foreground (s=0x7fffd1fa8de0) at xterm.c:1316 #9 0x00000000004e374d in x_draw_glyph_string (s=0x7fffd1fa8de0) at xterm.c:2708 #10 0x00000000004617cc in draw_glyphs (w=0x1cd5ad0, x=72, row=0x1f6fb20, area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504 #11 0x0000000000466f9c in x_write_glyphs (start=0x1fc1688, len=1) at xdisp.c:21913 ... ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1070: Looping in redisplay due to font problem 2008-10-07 16:14 ` bug#1070: " Chong Yidong @ 2008-10-08 1:16 ` Kenichi Handa 2008-10-08 15:50 ` Chong Yidong 0 siblings, 1 reply; 15+ messages in thread From: Kenichi Handa @ 2008-10-08 1:16 UTC (permalink / raw) To: Chong Yidong; +Cc: 1070 In article <87bpxwcrgk.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes: > > Please try to comment out all calls of XSetClipMask in > > x_draw_glyph_string, and check if Emacs loops in redisplay. > It still loops, though the backtrace is different now. Interrupting the > loop several times, I see that it gets stuck in two places within > xftfont_draw, at xftfont.c:561 and xftfont.c:549. > Another clue: I can't reproduce this bug on my 32-bit laptop, so maybe > it only shows up on 64-bit machines. Ummm. As I don't have 64-bit machines, it's difficult to find what is wrong :-( Do you see the same problem with the different font (or with the different size of the same font)? Do you see the same problem when you use only x font-backend? --- Kenichi Handa handa@ni.aist.go.jp ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1070: Looping in redisplay due to font problem 2008-10-08 1:16 ` Kenichi Handa @ 2008-10-08 15:50 ` Chong Yidong 0 siblings, 0 replies; 15+ messages in thread From: Chong Yidong @ 2008-10-08 15:50 UTC (permalink / raw) To: Kenichi Handa; +Cc: 1070 Kenichi Handa <handa@m17n.org> writes: > Ummm. As I don't have 64-bit machines, it's difficult to > find what is wrong :-( > > Do you see the same problem with the different font (or with > the different size of the same font)? > Do you see the same problem when you use only x font-backend? I see the same problem with different sizes of the same font (DejaVu Sans Mono), but the looping occurs at different places in the buffer. It doesn't happen with X font backend fonts, nor with other Xft fonts I tried (DejaVu Sans, Nimbus mono L, Jet, Dimnah, Terminus, Bitstream Vera Sans Mono). ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1105: marked as done (Looping in redisplay due to font problem) 2008-10-07 11:26 ` bug#1105: " Kenichi Handa 2008-10-07 16:14 ` bug#1070: " Chong Yidong @ 2008-10-09 16:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 15+ messages in thread From: Emacs bug Tracking System @ 2008-10-09 16:50 UTC (permalink / raw) To: Chong Yidong [-- Attachment #1: Type: text/plain, Size: 842 bytes --] Your message dated Thu, 09 Oct 2008 12:45:45 -0400 with message-id <873aj5lnt2.fsf@cyd.mit.edu> and subject line Re: Looping in redisplay due to font problem has caused the Emacs bug report #1070, regarding Looping in redisplay due to font problem to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 1070: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1070 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 3909 bytes --] From: Kenichi Handa <handa@m17n.org> To: Chong Yidong <cyd@stupidchicken.com> Cc: emacs-pretest-bug@gnu.org Subject: Re: Looping in redisplay due to font problem Date: Tue, 07 Oct 2008 20:26:01 +0900 Message-ID: <E1KnAhV-0007aZ-Vn@etlken.m17n.org> In article <87y711r87e.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes: > Yes, it always seems to stop at this place. Here's `bt full' and a > debugging session. I don't see anything wrong OTOH, and am unsure about > what to look for. Stepping forward in gdb doesn't work because the > program is stopped inside `select'. Any suggestions? > #0 0x00007f6dd0fe5433 in select () from /lib/libc.so.6 > #1 0x00007f6dcf0422b6 in ?? () from /usr/lib/libxcb.so.1 > #2 0x00007f6dcf0428eb in ?? () from /usr/lib/libxcb.so.1 > #3 0x00007f6dcf043050 in xcb_send_request () from /usr/lib/libxcb.so.1 > #4 0x00007f6dd1943f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 > #5 0x00007f6dd1944267 in ?? () from /usr/lib/libX11.so.6 > #6 0x00007f6dd19370bd in XSetClipMask () from /usr/lib/libX11.so.6 > #7 0x00000000004e426d in x_draw_glyph_string (s=0x7fffdd7a95e0) > at xterm.c:2883 > relief_drawn_p = 0 > #8 0x00000000004617cc in draw_glyphs (w=0x1cd5ad0, x=72, row=0x1f727d0, > area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) > at xdisp.c:20504 Please try to comment out all calls of XSetClipMask in x_draw_glyph_string, and check if Emacs loops in redisplay. --- Kenichi Handa handa@ni.aist.go.jp [-- Attachment #3: Type: message/rfc822, Size: 1291 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: 1070-done@emacsbugs.donarmstrong.com Subject: Re: Looping in redisplay due to font problem Date: Thu, 09 Oct 2008 12:45:45 -0400 Message-ID: <873aj5lnt2.fsf@cyd.mit.edu> I found the bug: it's an infloop in update_text_area which can happen when the pixel width of the current glyph is smaller than the lbearing of the next glyph. I'm not sure why the bug was triggered only under the situation I described; maybe, only that exact geometry and font produced the numbers leading to the infloop. I've checked in a fix. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1101: marked as done (Looping in redisplay due to font problem) 2008-10-06 16:37 ` bug#1101: " Chong Yidong 2008-10-07 11:26 ` bug#1105: " Kenichi Handa @ 2008-10-09 16:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 15+ messages in thread From: Emacs bug Tracking System @ 2008-10-09 16:50 UTC (permalink / raw) To: Chong Yidong [-- Attachment #1: Type: text/plain, Size: 842 bytes --] Your message dated Thu, 09 Oct 2008 12:45:45 -0400 with message-id <873aj5lnt2.fsf@cyd.mit.edu> and subject line Re: Looping in redisplay due to font problem has caused the Emacs bug report #1070, regarding Looping in redisplay due to font problem to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 1070: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1070 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 6746 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: emacs-pretest-bug@gnu.org Subject: Re: Looping in redisplay due to font problem Date: Mon, 06 Oct 2008 12:37:09 -0400 Message-ID: <87y711r87e.fsf@cyd.mit.edu> Kenichi Handa <handa@m17n.org> writes: >> #0 0x00007f54662e1433 in select () from /lib/libc.so.6 >> #1 0x00007f546403b2b6 in ?? () from /usr/lib/libxcb.so.1 >> #2 0x00007f546403b8eb in ?? () from /usr/lib/libxcb.so.1 >> #3 0x00007f546403c050 in xcb_send_request () from /usr/lib/libxcb.so.1 >> #4 0x00007f5466e71f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 >> #5 0x00007f5466e72267 in ?? () from /usr/lib/libX11.so.6 >> #6 0x00007f54650be5a3 in XRenderFillRectangle () from /usr/lib/libXrender.so.1 > > Does Emacs always stop at that place when you repeat "cont" > and "stop"? Yes, it always seems to stop at this place. Here's `bt full' and a debugging session. I don't see anything wrong OTOH, and am unsure about what to look for. Stepping forward in gdb doesn't work because the program is stopped inside `select'. Any suggestions? #0 0x00007f6dd0fe5433 in select () from /lib/libc.so.6 #1 0x00007f6dcf0422b6 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007f6dcf0428eb in ?? () from /usr/lib/libxcb.so.1 #3 0x00007f6dcf043050 in xcb_send_request () from /usr/lib/libxcb.so.1 #4 0x00007f6dd1943f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 #5 0x00007f6dd1944267 in ?? () from /usr/lib/libX11.so.6 #6 0x00007f6dd19370bd in XSetClipMask () from /usr/lib/libX11.so.6 #7 0x00000000004e426d in x_draw_glyph_string (s=0x7fffdd7a95e0) at xterm.c:2883 relief_drawn_p = 0 #8 0x00000000004617cc in draw_glyphs (w=0x1cd5ad0, x=72, row=0x1f727d0, area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504 head = (struct glyph_string *) 0x7fffdd7a95e0 tail = (struct glyph_string *) 0x7fffdd7a95e0 s = (struct glyph_string *) 0x7fffdd7a95e0 clip_head = (struct glyph_string *) 0x0 clip_tail = (struct glyph_string *) 0x0 i = 8 j = -579167284 x_reached = 72 last_x = 648 area_left = 8 f = (struct frame *) 0x19a52b0 #9 0x0000000000466f9c in x_write_glyphs (start=0x13de968, len=1) at xdisp.c:21913 x = 0 hpos = 7 #10 0x0000000000418fe2 in update_text_area (w=0x1cd5ad0, vpos=8) at dispnew.c:4585 start_x = 56 start_hpos = 7 start = (struct glyph *) 0x13de968 current_x = 64 skip_first_p = 0 can_skip_p = 1 stop = 33 i = 8 desired_glyph = (struct glyph *) 0x13de990 overlapping_glyphs_p = 1 desired_stop_pos = 62 x = 64 current_glyph = (struct glyph *) 0x1f8d8e0 current_row = (struct glyph_row *) 0xf63610 desired_row = (struct glyph_row *) 0x1f727d0 rif = (struct redisplay_interface *) 0x8a46c0 changed_p = 1 (gdb) f 8 #8 0x0000000000656170 in xftfont_draw (s=0x7fff461d8010, from=0, to=1, x=64, y=149, with_background=1) at xftfont.c:549 549 XftDrawRect (xft_draw, &bg, (gdb) p s $1 = (struct glyph_string *) 0x7fff461d8010 (gdb) p *s $2 = { x = 64, y = 136, ybase = 149, width = 8, background_width = 8, height = 17, left_overhang = 0, right_overhang = 0, f = 0x19a52b0, w = 0x1cd5ad0, display = 0xcb8790, window = 54526142, row = 0x1f6f7f0, area = TEXT_AREA, char2b = 0x7fff461d7ff0, nchars = 1, hl = DRAW_NORMAL_TEXT, face = 0x13cdae0, font = 0x1c04810, cmp = 0x0, cmp_id = 0, cmp_from = 0, cmp_to = 0, extends_to_end_of_line_p = 0, background_filled_p = 0, two_byte_p = 0, font_not_found_p = 0, stippled_p = 0, for_overlaps = 0, padding_p = 0, gc = 0xfbbf00, first_glyph = 0x13de968, img = 0x0, slice = { x = 0, y = 0, width = 0, height = 0 }, clip_head = 0x0, clip_tail = 0x0, clip = {{ x = 8, y = 136, width = 640, height = 17 }, { x = 0, y = 0, width = 0, height = 0 }}, num_clips = 1, underline_position = 0, underline_thickness = 0, next = 0x0, prev = 0x0 } (gdb) p *(s->font) $3 = { size = 4611686018429485074, next = 0x1c121e0, props = {12109345, 21852401, 18521457, 11665121, 12097873, 205440, 205056, 205312, 104, 11665121, 800, 0, 12327557, 11665121, 31929283, 31929251, 31929347, 18521505}, max_width = 0, pixel_size = 13, height = 17, space_width = 8, average_width = 8, min_width = 8, ascent = 13, descent = 4, underline_thickness = 0, underline_position = 0, vertical_centering = 0, encoding_type = 0 '\0', baseline_offset = 0, relative_compose = 0, default_ascent = 0, font_encoder = 0x1c04aa0, driver = 0xb16da0, encoding_charset = -1, repertory_charset = -1 } [-- Attachment #3: Type: message/rfc822, Size: 1291 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: 1070-done@emacsbugs.donarmstrong.com Subject: Re: Looping in redisplay due to font problem Date: Thu, 09 Oct 2008 12:45:45 -0400 Message-ID: <873aj5lnt2.fsf@cyd.mit.edu> I found the bug: it's an infloop in update_text_area which can happen when the pixel width of the current glyph is smaller than the lbearing of the next glyph. I'm not sure why the bug was triggered only under the situation I described; maybe, only that exact geometry and font produced the numbers leading to the infloop. I've checked in a fix. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1097: marked as done (Looping in redisplay due to font problem) 2008-10-06 2:32 ` bug#1097: " Kenichi Handa 2008-10-06 16:37 ` bug#1101: " Chong Yidong @ 2008-10-09 16:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 15+ messages in thread From: Emacs bug Tracking System @ 2008-10-09 16:50 UTC (permalink / raw) To: Chong Yidong [-- Attachment #1: Type: text/plain, Size: 842 bytes --] Your message dated Thu, 09 Oct 2008 12:45:45 -0400 with message-id <873aj5lnt2.fsf@cyd.mit.edu> and subject line Re: Looping in redisplay due to font problem has caused the Emacs bug report #1070, regarding Looping in redisplay due to font problem to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 1070: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1070 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 3689 bytes --] From: Kenichi Handa <handa@m17n.org> To: Chong Yidong <cyd@stupidchicken.com> Cc: emacs-pretest-bug@gnu.org Subject: Re: Looping in redisplay due to font problem Date: Mon, 06 Oct 2008 11:32:45 +0900 Message-ID: <E1Kmftt-0006Ka-IL@etlken.m17n.org> In article <87vdw91wl1.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes: > > And, what does "Emacs begins looping while in redisplay" exactly mean? > Emacs is unresponsive to any further input, and the character "o" in > "Corsivo" flickers. Interrupting the loop in gdb gives the following > backtrace. It seems to be stuck in an Xft function. > #0 0x00007f54662e1433 in select () from /lib/libc.so.6 > #1 0x00007f546403b2b6 in ?? () from /usr/lib/libxcb.so.1 > #2 0x00007f546403b8eb in ?? () from /usr/lib/libxcb.so.1 > #3 0x00007f546403c050 in xcb_send_request () from /usr/lib/libxcb.so.1 > #4 0x00007f5466e71f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 > #5 0x00007f5466e72267 in ?? () from /usr/lib/libX11.so.6 > #6 0x00007f54650be5a3 in XRenderFillRectangle () from /usr/lib/libXrender.so.1 > #7 0x00007f5466c1f5b1 in XftDrawRect () from /usr/lib/libXft.so.2 > #8 0x0000000000656080 in xftfont_draw (s=0x7fff725843b0, from=0, to=1, x=100, Does Emacs always stop at that place when you repeat "cont" and "stop"? --- Kenichi Handa handa@ni.aist.go.jp [-- Attachment #3: Type: message/rfc822, Size: 1291 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: 1070-done@emacsbugs.donarmstrong.com Subject: Re: Looping in redisplay due to font problem Date: Thu, 09 Oct 2008 12:45:45 -0400 Message-ID: <873aj5lnt2.fsf@cyd.mit.edu> I found the bug: it's an infloop in update_text_area which can happen when the pixel width of the current glyph is smaller than the lbearing of the next glyph. I'm not sure why the bug was triggered only under the situation I described; maybe, only that exact geometry and font produced the numbers leading to the infloop. I've checked in a fix. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1076: marked as done (Looping in redisplay due to font problem) 2008-10-03 16:18 ` bug#1076: " Chong Yidong 2008-10-06 2:32 ` bug#1097: " Kenichi Handa @ 2008-10-09 16:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 15+ messages in thread From: Emacs bug Tracking System @ 2008-10-09 16:50 UTC (permalink / raw) To: Chong Yidong [-- Attachment #1: Type: text/plain, Size: 842 bytes --] Your message dated Thu, 09 Oct 2008 12:45:45 -0400 with message-id <873aj5lnt2.fsf@cyd.mit.edu> and subject line Re: Looping in redisplay due to font problem has caused the Emacs bug report #1070, regarding Looping in redisplay due to font problem to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 1070: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1070 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 3966 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: emacs-pretest-bug@gnu.org Subject: Re: Looping in redisplay due to font problem Date: Fri, 03 Oct 2008 12:18:18 -0400 Message-ID: <87vdw91wl1.fsf@cyd.mit.edu> Kenichi Handa <handa@m17n.org> writes: > That's a very strange phenomenon. But, I can't reproduce > it. When I hit PageDown four times, the top line is "Luxi > Sans:style=Regular", and "Corsivo" appears on the 9th line > (logically 8th line because of continuation). > > In my case, this font is selected for the default case: > > -bitstream-Bitstream Vera Sans > Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1 > > Which font is selected in your case? C-u C-x = gives -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1 > And, what does "Emacs begins looping while in redisplay" exactly mean? Emacs is unresponsive to any further input, and the character "o" in "Corsivo" flickers. Interrupting the loop in gdb gives the following backtrace. It seems to be stuck in an Xft function. #0 0x00007f54662e1433 in select () from /lib/libc.so.6 #1 0x00007f546403b2b6 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007f546403b8eb in ?? () from /usr/lib/libxcb.so.1 #3 0x00007f546403c050 in xcb_send_request () from /usr/lib/libxcb.so.1 #4 0x00007f5466e71f1a in _XPutXCBBuffer () from /usr/lib/libX11.so.6 #5 0x00007f5466e72267 in ?? () from /usr/lib/libX11.so.6 #6 0x00007f54650be5a3 in XRenderFillRectangle () from /usr/lib/libXrender.so.1 #7 0x00007f5466c1f5b1 in XftDrawRect () from /usr/lib/libXft.so.2 #8 0x0000000000656080 in xftfont_draw (s=0x7fff725843b0, from=0, to=1, x=100, y=175, with_background=1) at xftfont.c:549 #9 0x00000000004e0268 in x_draw_glyph_string_foreground (s=0x7fff725843b0) at xterm.c:1316 #10 0x00000000004e374c in x_draw_glyph_string (s=0x7fff725843b0) at xterm.c:2708 #11 0x00000000004616f1 in draw_glyphs (w=0x17ec430, x=110, row=0x1f49b20, area=TEXT_AREA, start=7, end=8, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:20504 #12 0x0000000000466ec1 in x_write_glyphs (start=0x145f748, len=1) at xdisp.c:21913 #13 0x0000000000418fa4 in update_text_area (w=0x17ec430, vpos=8) at dispnew.c:4584 ... [-- Attachment #3: Type: message/rfc822, Size: 1291 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: 1070-done@emacsbugs.donarmstrong.com Subject: Re: Looping in redisplay due to font problem Date: Thu, 09 Oct 2008 12:45:45 -0400 Message-ID: <873aj5lnt2.fsf@cyd.mit.edu> I found the bug: it's an infloop in update_text_area which can happen when the pixel width of the current glyph is smaller than the lbearing of the next glyph. I'm not sure why the bug was triggered only under the situation I described; maybe, only that exact geometry and font produced the numbers leading to the infloop. I've checked in a fix. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1071: marked as done (Looping in redisplay due to font problem) 2008-10-03 1:24 ` bug#1071: " Kenichi Handa 2008-10-03 16:18 ` bug#1076: " Chong Yidong @ 2008-10-09 16:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 15+ messages in thread From: Emacs bug Tracking System @ 2008-10-09 16:50 UTC (permalink / raw) To: Chong Yidong [-- Attachment #1: Type: text/plain, Size: 842 bytes --] Your message dated Thu, 09 Oct 2008 12:45:45 -0400 with message-id <873aj5lnt2.fsf@cyd.mit.edu> and subject line Re: Looping in redisplay due to font problem has caused the Emacs bug report #1070, regarding Looping in redisplay due to font problem to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 1070: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1070 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 3956 bytes --] From: Kenichi Handa <handa@m17n.org> To: Chong Yidong <cyd@stupidchicken.com> Cc: emacs-pretest-bug@gnu.org Subject: Re: Looping in redisplay due to font problem Date: Fri, 03 Oct 2008 10:24:18 +0900 Message-ID: <E1KlZP0-0001GA-VP@etlken.m17n.org> In article <878wt6a7aq.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes: > After the 2008-07-09 change to ftfont.c, Emacs can loop during redisplay > under the following conditions: > xrdb /dev/null > emacs -Q fc-list.list [fc-list.list is attached] > <PageDown> > <PageDown> > <PageDown> > <PageDown> > Emacs begins looping while in redisplay, while displaying the text > "Corsivo" (the final letter "o" blinks rapidly). > Strangely enough, I can't reproduce this if I substitute C-v for > PageDown (?!??!). Also, the bug doesn't show up if there is an X > resource Emacs.geometry already defined. > The problem seems to have appeared for the first time during the checkin > listed below. My tests indicate that the other files involved this > checkin do not affect the problem. > Could you see if you can reproduce this problem, and review the code > changes to see if they may have caused it? Thanks! That's a very strange phenomenon. But, I can't reproduce it. When I hit PageDown four times, the top line is "Luxi Sans:style=Regular", and "Corsivo" appears on the 9th line (logically 8th line because of continuation). In my case, this font is selected for the default case: -bitstream-Bitstream Vera Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1 Which font is selected in your case? And, what does "Emacs begins looping while in redisplay" exactly mean? --- Kenichi Handa handa@ni.aist.go.jp [-- Attachment #3: Type: message/rfc822, Size: 1291 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: 1070-done@emacsbugs.donarmstrong.com Subject: Re: Looping in redisplay due to font problem Date: Thu, 09 Oct 2008 12:45:45 -0400 Message-ID: <873aj5lnt2.fsf@cyd.mit.edu> I found the bug: it's an infloop in update_text_area which can happen when the pixel width of the current glyph is smaller than the lbearing of the next glyph. I'm not sure why the bug was triggered only under the situation I described; maybe, only that exact geometry and font produced the numbers leading to the infloop. I've checked in a fix. ^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#1070: marked as done (Looping in redisplay due to font problem) 2008-10-02 23:47 ` bug#1070: Looping in redisplay due to font problem Chong Yidong 2008-10-03 1:24 ` bug#1071: " Kenichi Handa @ 2008-10-09 16:50 ` Emacs bug Tracking System 1 sibling, 0 replies; 15+ messages in thread From: Emacs bug Tracking System @ 2008-10-09 16:50 UTC (permalink / raw) To: Chong Yidong [-- Attachment #1: Type: text/plain, Size: 842 bytes --] Your message dated Thu, 09 Oct 2008 12:45:45 -0400 with message-id <873aj5lnt2.fsf@cyd.mit.edu> and subject line Re: Looping in redisplay due to font problem has caused the Emacs bug report #1070, regarding Looping in redisplay due to font problem to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) -- 1070: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1070 Emacs Bug Tracking System Contact don@donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 3839 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: emacs-pretest-bug@gnu.org Subject: Looping in redisplay due to font problem Date: Thu, 02 Oct 2008 19:47:25 -0400 Message-ID: <878wt6a7aq.fsf@cyd.mit.edu> After the 2008-07-09 change to ftfont.c, Emacs can loop during redisplay under the following conditions: xrdb /dev/null emacs -Q fc-list.list [fc-list.list is attached] <PageDown> <PageDown> <PageDown> <PageDown> Emacs begins looping while in redisplay, while displaying the text "Corsivo" (the final letter "o" blinks rapidly). Strangely enough, I can't reproduce this if I substitute C-v for PageDown (?!??!). Also, the bug doesn't show up if there is an X resource Emacs.geometry already defined. The problem seems to have appeared for the first time during the checkin listed below. My tests indicate that the other files involved this checkin do not affect the problem. Could you see if you can reproduce this problem, and review the code changes to see if they may have caused it? Thanks! 2008-07-09 Kenichi Handa <handa@m17n.org> * ftfont.c (struct ftfont_info): New member index, delete member fc_charset_idx. Make the member order compatible with struct xftfont_info. (fc_charset_table): Change charset names to registry names. (ftfont_pattern_entity): Delete the args registry and fc_charset_idx. Change the value of :font-entity property to (FONTNAME . INDEX). Always set :registry property to `iso10646-1'. (struct ftfont_cache_data): New struct. (ftfont_lookup_cache): New arg for_face. (ftfont_get_fc_charset, ftfont_get_otf): New functions. (ftfont_driver): Set the member otf_capability. (ftfont_get_charset): Adjust it for the change of fc_charset_table. (OTF_TAG_SYM): New macro. (ftfont_spec_pattern): Delete the arg fc_charset_idx. Adjust it for the change of fc_charset_table. (ftfont_list): Adjust it for the change of ftfont_spec_pattern and ftfont_pattern_entity. Add FC_INDEX to objset. (ftfont_match): Adjust it for the change of ftfont_spec_pattern and ftfont_pattern_entity. (ftfont_open): Adjust it for the change of ftfont_lookup_cache, font_make_object, struct ftfont_info. (ftfont_has_char): Use ftfont_get_fc_charset. (ftfont_otf_features, ftfont_otf_capability): New functions. (ftfont_shape): Use ftfont_get_otf. (ftfont_text_extents): Fix initial setting of metrics. [-- Attachment #3: Type: message/rfc822, Size: 1291 bytes --] From: Chong Yidong <cyd@stupidchicken.com> To: Kenichi Handa <handa@m17n.org> Cc: 1070-done@emacsbugs.donarmstrong.com Subject: Re: Looping in redisplay due to font problem Date: Thu, 09 Oct 2008 12:45:45 -0400 Message-ID: <873aj5lnt2.fsf@cyd.mit.edu> I found the bug: it's an infloop in update_text_area which can happen when the pixel width of the current glyph is smaller than the lbearing of the next glyph. I'm not sure why the bug was triggered only under the situation I described; maybe, only that exact geometry and font produced the numbers leading to the infloop. I've checked in a fix. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-10-09 16:50 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <873aj5lnt2.fsf@cyd.mit.edu> 2008-10-02 23:47 ` bug#1070: Looping in redisplay due to font problem Chong Yidong 2008-10-03 1:24 ` bug#1071: " Kenichi Handa 2008-10-03 16:18 ` bug#1076: " Chong Yidong 2008-10-06 2:32 ` bug#1097: " Kenichi Handa 2008-10-06 16:37 ` bug#1101: " Chong Yidong 2008-10-07 11:26 ` bug#1105: " Kenichi Handa 2008-10-07 16:14 ` bug#1070: " Chong Yidong 2008-10-08 1:16 ` Kenichi Handa 2008-10-08 15:50 ` Chong Yidong 2008-10-09 16:50 ` bug#1105: marked as done (Looping in redisplay due to font problem) Emacs bug Tracking System 2008-10-09 16:50 ` bug#1101: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1097: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1076: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1071: " Emacs bug Tracking System 2008-10-09 16:50 ` bug#1070: " Emacs bug Tracking System
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.