GNU bug report logs - #31316
Emacs hangs in `font_open_entity'

Previous Next

Package: emacs;

Reported by: Werner LEMBERG <wl <at> gnu.org>

Date: Mon, 30 Apr 2018 08:14:01 UTC

Severity: normal

Tags: moreinfo

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Mon, 30 Apr 2018 08:14:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner LEMBERG <wl <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 30 Apr 2018 08:14:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Werner LEMBERG <wl <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs hangs in `font_open_entity'
Date: Mon, 30 Apr 2018 10:13:08 +0200 (CEST)

If I call `emacs -Q' and load the attached file `testchar' with

  C-x RET c gb18030 C-x C-f testchar

Emacs hangs in `font_open_entity' on my GNU/Linux box:

  for (psize = pixel_size; ; psize++)
    {
      font_object = driver_list->driver->open (f, entity, psize);
      if (NILP (font_object))
        return Qnil;
      font = XFONT_OBJECT (font_object);
      if (font->average_width > 0 && font->height > 0)
        break;
    }

Both `average_width' and `height' are always zero for `font'
regardless of `psize'; this effectively makes the above code an
endless loop.



In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.20.10)
 of 2018-04-30 built on linux
Repository revision: bca6c4348077c8c0b368503b16378867b6d49659
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description: openSUSE Leap 42.3

Recent messages:
Setting up Mew world...
Updating status...done
Setting up Mew world...done
Scanning +inbox...done
(New file)
Saving file /home/wl/Mail/draft/2...
Wrote /home/wl/Mail/draft/2
Draft is prepared
Kill draft message? (y or n) y
Draft was killed

Configured using:
 'configure MAKEINFO=/usr/bin/makeinfo --with-x-toolkit=gtk
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3 -gdwarf-4''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 THREADS LIBSYSTEMD JSON LCMS2

Important settings:
  value of $LANG: de_AT.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Summary

Minor modes in effect:
  TeX-PDF-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/usr/local/share/emacs/site-lisp/thai-word hides /usr/local/share/emacs/27.0.50/lisp/language/thai-word

Features:
(shadow emacsbug message rmc puny dired dired-loaddefs format-spec
rfc822 mml mml-sec epa gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils pp mew-varsx mew-unix
time-date elec-pair edmacro kmacro rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap nxml-util nxml-enc xmltok sgml-mode dom
hideshow cal-menu calendar cal-loaddefs mew-auth mew-config mew-imap2
mew-imap mew-nntp2 mew-nntp mew-pop mew-smtp mew-ssl mew-ssh mew-net
mew-highlight mew-sort mew-fib mew-ext mew-refile mew-demo mew-attach
mew-draft mew-message mew-thread mew-virtual mew-summary4 mew-summary3
mew-summary2 mew-summary mew-search mew-pick mew-passwd mew-scan
mew-syntax mew-bq mew-smime mew-pgp mew-header mew-exec mew-mark
mew-mime mew-edit mew-decode mew-encode mew-cache mew-minibuf
mew-complete mew-addrbook mew-local mew-vars3 mew-vars2 mew-vars
mew-env mew-mule3 mew-mule mew-gemacs mew-key mew-func mew-blvs
mew-const mew tex dbus xml crm advice auto-loads tex-site quail
cjktilde mm-util mail-prsvr disp-table finder-inf package let-alist
derived pcase cl-extra help-mode easymenu url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars seq byte-opt gv bytecomp byte-compile
cconv epg epg-config subr-x cl-loaddefs cl-lib mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow
isearch timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 218273 12220)
 (symbols 48 30642 1)
 (miscs 40 254 176)
 (strings 32 70199 1287)
 (string-bytes 1 1788529)
 (vectors 16 27708)
 (vector-slots 8 781202 22292)
 (floats 8 80 37)
 (intervals 56 1514 152)
 (buffers 992 12)
 (heap 1024 36966 1819))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Mon, 30 Apr 2018 08:17:01 GMT) Full text and rfc822 format available.

Message #8 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Werner LEMBERG <wl <at> gnu.org>
To: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Mon, 30 Apr 2018 10:16:48 +0200 (CEST)
[Message part 1 (text/plain, inline)]
> 
> If I call `emacs -Q' and load the attached file `testchar' with
> 
>   C-x RET c gb18030 C-x C-f testchar

Oops, here is the file.
[testchar (text/plain, inline)]
華や

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Mon, 30 Apr 2018 15:22:01 GMT) Full text and rfc822 format available.

Message #11 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Mon, 30 Apr 2018 18:21:12 +0300
> Date: Mon, 30 Apr 2018 10:13:08 +0200 (CEST)
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> If I call `emacs -Q' and load the attached file `testchar' with
> 
>   C-x RET c gb18030 C-x C-f testchar
> 
> Emacs hangs in `font_open_entity' on my GNU/Linux box:
> 
>   for (psize = pixel_size; ; psize++)
>     {
>       font_object = driver_list->driver->open (f, entity, psize);
>       if (NILP (font_object))
>         return Qnil;
>       font = XFONT_OBJECT (font_object);
>       if (font->average_width > 0 && font->height > 0)
>         break;
>     }

Does the patch below solve this without introducing any new problems?

> Both `average_width' and `height' are always zero for `font'
> regardless of `psize'; this effectively makes the above code an
> endless loop.

What kind of strange font has both of these always zero?

diff --git a/src/font.c b/src/font.c
index ef3f92b..daa6be0 100644
--- a/src/font.c
+++ b/src/font.c
@@ -2901,7 +2901,9 @@ font_open_entity (struct frame *f, Lisp_Object entity, int pixel_size)
   for (psize = pixel_size; ; psize++)
     {
       font_object = driver_list->driver->open (f, entity, psize);
-      if (NILP (font_object))
+      if (NILP (font_object)
+	  /* Avoid an infinite loop.  */
+	  || psize > pixel_size + 100)
 	return Qnil;
       font = XFONT_OBJECT (font_object);
       if (font->average_width > 0 && font->height > 0)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Mon, 30 Apr 2018 17:23:01 GMT) Full text and rfc822 format available.

Message #14 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Werner LEMBERG <wl <at> gnu.org>
To: eliz <at> gnu.org
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Mon, 30 Apr 2018 19:22:18 +0200 (CEST)
>> If I call `emacs -Q' and load the attached file `testchar' with
>> 
>>   C-x RET c gb18030 C-x C-f testchar
>> 
>> Emacs hangs in `font_open_entity' on my GNU/Linux box:
> 
> Does the patch below solve this without introducing any new
> problems?

Sort of, thanks.  After waiting a few seconds, Emacs now displays
three characters, but navigation is hard: it takes a few seconds to
move from character to character (I guess Emacs tries to reload the
missing glyph again and again).

>> Both `average_width' and `height' are always zero for `font'
>> regardless of `psize'; this effectively makes the above code an
>> endless loop.
> 
> What kind of strange font has both of these always zero?

If you tell me how to find out the name of the font Emacs tries to
use, I can try to answer this question.


    Werner




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Mon, 30 Apr 2018 19:46:01 GMT) Full text and rfc822 format available.

Message #17 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Mon, 30 Apr 2018 22:44:49 +0300
> Date: Mon, 30 Apr 2018 19:22:18 +0200 (CEST)
> Cc: 31316 <at> debbugs.gnu.org
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> >> If I call `emacs -Q' and load the attached file `testchar' with
> >> 
> >>   C-x RET c gb18030 C-x C-f testchar
> >> 
> >> Emacs hangs in `font_open_entity' on my GNU/Linux box:
> > 
> > Does the patch below solve this without introducing any new
> > problems?
> 
> Sort of, thanks.  After waiting a few seconds, Emacs now displays
> three characters, but navigation is hard: it takes a few seconds to
> move from character to character (I guess Emacs tries to reload the
> missing glyph again and again).

Well, maybe I went overboard with the 100 figure, and we should use a
much smaller number, like 10 or 20?

And anyway, some delays are better than an infloop, yes?

> >> Both `average_width' and `height' are always zero for `font'
> >> regardless of `psize'; this effectively makes the above code an
> >> endless loop.
> > 
> > What kind of strange font has both of these always zero?
> 
> If you tell me how to find out the name of the font Emacs tries to
> use, I can try to answer this question.

Put a breakpoint in the loop, and when it breaks, say

  (gdb) pp entity

(You will need to make sure src/.gdbinit in the Emacs tree is read by
GDB, before "pp" will work for you.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Mon, 30 Apr 2018 20:21:02 GMT) Full text and rfc822 format available.

Message #20 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Werner LEMBERG <wl <at> gnu.org>
To: eliz <at> gnu.org
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Mon, 30 Apr 2018 22:20:13 +0200 (CEST)
Eli, thanks for the `pp' tip.

>> Sort of, thanks.  After waiting a few seconds, Emacs now displays
>> three characters, but navigation is hard: it takes a few seconds to
>> move from character to character (I guess Emacs tries to reload the
>> missing glyph again and again).
> 
> Well, maybe I went overboard with the 100 figure, and we should use
> a much smaller number, like 10 or 20?

Maybe, yes.  I don't know enough of Emacs code to have an opinion on
that.

> And anyway, some delays are better than an infloop, yes?

Certainly.  However, I wonder why Emacs doesn't cache this...

>> >> Both `average_width' and `height' are always zero for `font'
>> >> regardless of `psize'; this effectively makes the above code an
>> >> endless loop.
>>
>> > What kind of strange font has both of these always zero?

I have to correct me: Only `average_width' is zero, not value
`height'.

The font is called `emmentaler-brace.otf' (part of lilypond,
containing system braces for musical scores).  However, I wonder how
this font can ever be considered as a fallback, since its SFNT (3,1)
Unicode cmap contains only PUA character codes in the range
0xe100-0xe33f (and `fc-list -v' correctly lists that).  In other
words, this font definitely doesn't contain anything relevant to the
CJK character codes originally reported.


    Werner




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Tue, 01 May 2018 15:07:02 GMT) Full text and rfc822 format available.

Message #23 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Tue, 01 May 2018 18:06:04 +0300
> Date: Mon, 30 Apr 2018 22:20:13 +0200 (CEST)
> Cc: 31316 <at> debbugs.gnu.org
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> The font is called `emmentaler-brace.otf' (part of lilypond,
> containing system braces for musical scores).  However, I wonder how
> this font can ever be considered as a fallback, since its SFNT (3,1)
> Unicode cmap contains only PUA character codes in the range
> 0xe100-0xe33f (and `fc-list -v' correctly lists that).  In other
> words, this font definitely doesn't contain anything relevant to the
> CJK character codes originally reported.

Please show a C-level backtrace from a breakpoint in that loop.  And
if the breakpoint breaks more than once when you do nothing after
invoking Emacs as shown in your OP, please show the backtraces from
all the times that breakpoint breaks.

Maybe looking at the backtrace will help us understand why Emacs
attempts to open that font.  Two general remarks I can make at this
point are that (a) Emacs decides whether a font might support a
character _without_ opening it (because opening a font is expensive,
and doing that for hundreds of fonts on a typical system will make
Emacs very annoying), and (b) only some font back-ends use Fontconfig,
so the fact that fc knows something doesn't yet mean Emacs does.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Sat, 05 May 2018 08:56:01 GMT) Full text and rfc822 format available.

Message #26 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Sat, 05 May 2018 11:55:39 +0300
> Date: Mon, 30 Apr 2018 22:20:13 +0200 (CEST)
> Cc: 31316 <at> debbugs.gnu.org
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> >> Sort of, thanks.  After waiting a few seconds, Emacs now displays
> >> three characters, but navigation is hard: it takes a few seconds to
> >> move from character to character (I guess Emacs tries to reload the
> >> missing glyph again and again).
> > 
> > Well, maybe I went overboard with the 100 figure, and we should use
> > a much smaller number, like 10 or 20?
> 
> Maybe, yes.  I don't know enough of Emacs code to have an opinion on
> that.

I eventually went with 15.  Pushed to the master branch.

> The font is called `emmentaler-brace.otf' (part of lilypond,
> containing system braces for musical scores).  However, I wonder how
> this font can ever be considered as a fallback, since its SFNT (3,1)
> Unicode cmap contains only PUA character codes in the range
> 0xe100-0xe33f (and `fc-list -v' correctly lists that).  In other
> words, this font definitely doesn't contain anything relevant to the
> CJK character codes originally reported.

I asked for a backtrace from that loop:

> Please show a C-level backtrace from a breakpoint in that loop.  And
> if the breakpoint breaks more than once when you do nothing after
> invoking Emacs as shown in your OP, please show the backtraces from
> all the times that breakpoint breaks.
> 
> Maybe looking at the backtrace will help us understand why Emacs
> attempts to open that font.

Can you please produce that?  I'd like to close this bug report, but
maybe the backtrace will show us that something else should be done
here.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Tue, 08 May 2018 20:21:02 GMT) Full text and rfc822 format available.

Message #29 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Werner LEMBERG <wl <at> gnu.org>
To: eliz <at> gnu.org
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Tue, 08 May 2018 22:20:27 +0200 (CEST)
[Message part 1 (text/plain, inline)]
>> The font is called `emmentaler-brace.otf' (part of lilypond,
>> containing system braces for musical scores).  However, I wonder
>> how this font can ever be considered as a fallback, since its SFNT
>> (3,1) Unicode cmap contains only PUA character codes in the range
>> 0xe100-0xe33f (and `fc-list -v' correctly lists that).  In other
>> words, this font definitely doesn't contain anything relevant to
>> the CJK character codes originally reported.
> 
> I asked for a backtrace from that loop:
> 
>> Please show a C-level backtrace from a breakpoint in that loop.
>> And if the breakpoint breaks more than once when you do nothing
>> after invoking Emacs as shown in your OP, please show the
>> backtraces from all the times that breakpoint breaks.
>>
>> Maybe looking at the backtrace will help us understand why Emacs
>> attempts to open that font.
> 
> Can you please produce that?  I'd like to close this bug report, but
> maybe the backtrace will show us that something else should be done
> here.

Attached. It contains all breaks between loading the test file in
GB18030 encoding and displaying something on screen.

This is still emacs bca6c434 (Apr 29).

Calling `pp entity' at each break shows the following fonts.

  #<font-entity xft 1ASC Droid\ Sans\ Fallback nil iso10646-1 normal normal normal 0 nil nil 0 ((:font-entity "/usr/share/fonts/truetype/DroidSansFallbackFull.ttf" . 0))>
  #<font-entity xft ADBO Source\ Code\ Pro nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/SourceCodePro-Regular.otf" . 0))>
  #<font-entity xft PfEd Emmentaler-Brace nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/home/wl/.fonts/texlive/opentype/public/lilyglyphs/emmentaler-brace.otf" . 0))>
  #<font-entity xft ADBO Source\ Code\ Pro nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/SourceCodePro-Regular.otf" . 0))>
  #<font-entity xft PfEd Emmentaler-Brace nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/home/wl/.fonts/texlive/opentype/public/lilyglyphs/emmentaler-brace.otf" . 0))>
  #<font-entity xft ADBO Source\ Code\ Pro nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/SourceCodePro-Regular.otf" . 0))>
  #<font-entity xft PfEd Emmentaler-Brace nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/home/wl/.fonts/texlive/opentype/public/lilyglyphs/emmentaler-brace.otf" . 0))>
  #<font-entity xft PfEd Emmentaler-Brace nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/home/wl/.fonts/texlive/opentype/public/lilyglyphs/emmentaler-brace.otf" . 0))>
  #<font-entity xft PfEd Emmentaler-Brace nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/home/wl/.fonts/texlive/opentype/public/lilyglyphs/emmentaler-brace.otf" . 0))>
  #<font-entity xft PfEd Emmentaler-Brace nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/home/wl/.fonts/texlive/opentype/public/lilyglyphs/emmentaler-brace.otf" . 0))>


    Werner
[gdb.txt.xz (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Tue, 08 May 2018 20:50:02 GMT) Full text and rfc822 format available.

Message #32 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Werner LEMBERG <wl <at> gnu.org>
To: eliz <at> gnu.org
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Tue, 08 May 2018 22:49:30 +0200 (CEST)
For completeness:

> Attached. It contains all breaks between loading the test file in
> GB18030 encoding and displaying something on screen.
> 
> This is still emacs bca6c434 (Apr 29).

... with the following local patches (which don't influence the
selection of fonts, still leading to the problematic `Emmentaler'
font).


    Werner


PS: Why doesn't produce the `pp' command (from emacs's `.gdbinit'
    file) any output in `gdb.txt' if activated with `set logging on'?


======================================================================


diff --git a/lisp/international/fontset.el b/lisp/international/fontset.el
index 4a7b754791..47f8c9ad3a 100644
--- a/lisp/international/fontset.el
+++ b/lisp/international/fontset.el
@@ -53,7 +53,7 @@
        ("ascii-0$" . ascii)
        ("gb2312.1980" . chinese-gb2312)
        ("gbk" . chinese-gbk)
-       ("gb18030" . (unicode . nil))
+       ("gb18030" . (gb18030 . unicode))
        ("jisx0208.1978" . japanese-jisx0208-1978)
        ("jisx0208" . japanese-jisx0208)
        ("jisx0201" . jisx0201)
diff --git a/src/font.c b/src/font.c
index ef3f92b594..daa6be00e6 100644
--- a/src/font.c
+++ b/src/font.c
@@ -2901,7 +2901,9 @@ font_open_entity (struct frame *f, Lisp_Object entity, int pixel_size)
   for (psize = pixel_size; ; psize++)
     {
       font_object = driver_list->driver->open (f, entity, psize);
-      if (NILP (font_object))
+      if (NILP (font_object)
+         /* Avoid an infinite loop.  */
+         || psize > pixel_size + 100)
        return Qnil;
       font = XFONT_OBJECT (font_object);
       if (font->average_width > 0 && font->height > 0)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Sun, 17 Nov 2019 08:24:01 GMT) Full text and rfc822 format available.

Message #35 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: 31316 <at> debbugs.gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Sun, 17 Nov 2019 09:23:07 +0100
Werner LEMBERG <wl <at> gnu.org> writes:

> If I call `emacs -Q' and load the attached file `testchar' with
>
>   C-x RET c gb18030 C-x C-f testchar
>
> Emacs hangs in `font_open_entity' on my GNU/Linux box:
>
>   for (psize = pixel_size; ; psize++)
>     {
>       font_object = driver_list->driver->open (f, entity, psize);
>       if (NILP (font_object))
>         return Qnil;
>       font = XFONT_OBJECT (font_object);
>       if (font->average_width > 0 && font->height > 0)
>         break;
>     }
>
> Both `average_width' and `height' are always zero for `font'
> regardless of `psize'; this effectively makes the above code an
> endless loop.

I tried reproducing this with Emacs 27 (on a Debian laptop), and I get
no hangs.  Are you still seeing this problem?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 17 Nov 2019 08:24:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Sun, 17 Nov 2019 15:57:01 GMT) Full text and rfc822 format available.

Message #40 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 31316 <at> debbugs.gnu.org, wl <at> gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Sun, 17 Nov 2019 17:55:57 +0200
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 17 Nov 2019 09:23:07 +0100
> Cc: 31316 <at> debbugs.gnu.org
> 
> >   for (psize = pixel_size; ; psize++)
> >     {
> >       font_object = driver_list->driver->open (f, entity, psize);
> >       if (NILP (font_object))
> >         return Qnil;
> >       font = XFONT_OBJECT (font_object);
> >       if (font->average_width > 0 && font->height > 0)
> >         break;
> >     }
> >
> > Both `average_width' and `height' are always zero for `font'
> > regardless of `psize'; this effectively makes the above code an
> > endless loop.
> 
> I tried reproducing this with Emacs 27 (on a Debian laptop), and I get
> no hangs.  Are you still seeing this problem?

The infloop was fixed in commit e2879c1.

There was an additional issue that caused the bug to remain open, but
I think we can close this now.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#31316; Package emacs. (Sun, 17 Nov 2019 16:06:02 GMT) Full text and rfc822 format available.

Message #43 received at 31316 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31316 <at> debbugs.gnu.org, wl <at> gnu.org
Subject: Re: bug#31316: Emacs hangs in `font_open_entity'
Date: Sun, 17 Nov 2019 17:05:31 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

> There was an additional issue that caused the bug to remain open, but
> I think we can close this now.

OK; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 31316 <at> debbugs.gnu.org and Werner LEMBERG <wl <at> gnu.org> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 17 Nov 2019 16:06:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 16 Dec 2019 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 104 days ago.

Previous Next


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