GNU bug report logs - #1070
Looping in redisplay due to font problem

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1070 in the body.
You can then email your comments to 1070 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa  <handa <at> m17n.org>
Cc: emacs-pretest-bug <at> gnu.org
Subject: Looping in redisplay due to font problem
Date: Thu, 02 Oct 2008 19:47:25 -0400

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

Message #10 received at 1070 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa  <handa <at> m17n.org>
Cc: 1070 <at> debbugs.gnu.org
Subject: Re: Looping in redisplay due to font problem 
Date: Thu, 02 Oct 2008 19:58:41 -0400

[Message part 1 (text/plain, inline)]

I forgot to attach the file fclist.list which reproduces this problem:
here it is.

[fc-list.list (application/octet-stream, attachment)]

Message #23 received at 1070 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 1070 <at> debbugs.gnu.org
Subject: Re: Looping in redisplay due to font problem
Date: Tue, 07 Oct 2008 12:14:51 -0400

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

Message #30 received at 1070 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 1070 <at> debbugs.gnu.org
Subject: Re: Looping in redisplay due to font problem
Date: Wed, 08 Oct 2008 10:16:32 +0900

In article <87bpxwcrgk.fsf <at> cyd.mit.edu>, Chong Yidong <cyd <at> 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 <at> ni.aist.go.jp

Message #35 received at 1070 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 1070 <at> debbugs.gnu.org
Subject: Re: Looping in redisplay due to font problem
Date: Wed, 08 Oct 2008 11:50:21 -0400

Kenichi Handa <handa <at> 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).

Message #40 received at 1070-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa  <handa <at> m17n.org>
Cc: 1070-done <at> debbugs.gnu.org
Subject: Re: Looping in redisplay due to font problem
Date: Thu, 09 Oct 2008 12:45:45 -0400

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.

Message #66 received at 1070-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 1070-done <at> debbugs.gnu.org
Subject: Re: Looping in redisplay due to font problem
Date: Fri, 10 Oct 2008 10:09:28 +0900

In article <873aj5lnt2.fsf <at> cyd.mit.edu>, Chong Yidong <cyd <at> stupidchicken.com> writes:

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

Thank you!  But, I don't understand why the bug is triggered
only on 64-bit machine.

---
Kenichi Handa
handa <at> ni.aist.go.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.