bug#1070: Looping in redisplay due to font problem

bug#1070: Looping in redisplay due to font problem

[Chong Yidong]

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.

bug#1071: Looping in redisplay due to font problem

[Kenichi Handa]

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

bug#1076: Looping in redisplay due to font problem

[Chong Yidong]

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
...

bug#1097: Looping in redisplay due to font problem

[Kenichi Handa]

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

bug#1101: Looping in redisplay due to font problem

[Chong Yidong]

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
}

bug#1105: Looping in redisplay due to font problem

[Kenichi Handa]

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

bug#1070: Looping in redisplay due to font problem

[Chong Yidong]

> 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
...

bug#1070: Looping in redisplay due to font problem

[Kenichi Handa]

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

bug#1070: Looping in redisplay due to font problem

[Chong Yidong]

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).

bug#1070: marked as done (Looping in redisplay due to font problem)

[Emacs bug Tracking System]

[-- 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.

bug#1071: marked as done (Looping in redisplay due to font problem)

[Emacs bug Tracking System]

[-- 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.

bug#1076: marked as done (Looping in redisplay due to font problem)

[Emacs bug Tracking System]

[-- 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.

bug#1105: marked as done (Looping in redisplay due to font problem)

[Emacs bug Tracking System]

[-- 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.

bug#1097: marked as done (Looping in redisplay due to font problem)

[Emacs bug Tracking System]

[-- 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.

bug#1101: marked as done (Looping in redisplay due to font problem)

[Emacs bug Tracking System]

[-- 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.