From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30874: 27.0.50; Emacs crashes Date: Fri, 30 Mar 2018 14:46:31 +0300 Message-ID: <83po3l946g.fsf@gnu.org> References: <837eq7lzr4.fsf@gnu.org> <831sgencgb.fsf@gnu.org> <83woy4i7rz.fsf@gnu.org> <83vadoi2ia.fsf@gnu.org> <878taf2kj5.fsf@gmail.com> <83d0zqg8p8.fsf@gnu.org> <87o9ja230e.fsf@gmail.com> <83605ig2se.fsf@gnu.org> <87fu4m1tht.fsf@gmail.com> <878tae1nzu.fsf@gmail.com> <83lgeedxv7.fsf@gnu.org> <874ll128ww.fsf@gmail.com> <83efk3dvq0.fsf@gnu.org> <87po3mdfl8.fsf@gmail.com> <83sh8idd3p.fsf@gnu.org> <87woxtq282.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1522410320 14039 195.159.176.226 (30 Mar 2018 11:45:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 11:45:20 +0000 (UTC) Cc: 30874@debbugs.gnu.org, jsynacek@redhat.com To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 30 13:45:16 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1sT5-0003XZ-MN for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2018 13:45:15 +0200 Original-Received: from localhost ([::1]:57296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1sV9-0003rK-1i for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Mar 2018 07:47:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1sUr-0003oo-Ux for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 07:47:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1sUo-0008Hj-Qz for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 07:47:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51571) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1sUo-0008Hd-N5 for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 07:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1sUo-0000t0-Fm for bug-gnu-emacs@gnu.org; Fri, 30 Mar 2018 07:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Mar 2018 11:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30874 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30874-submit@debbugs.gnu.org id=B30874.15224104112838 (code B ref 30874); Fri, 30 Mar 2018 11:47:02 +0000 Original-Received: (at 30874) by debbugs.gnu.org; 30 Mar 2018 11:46:51 +0000 Original-Received: from localhost ([127.0.0.1]:59468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1sUc-0000jR-Q1 for submit@debbugs.gnu.org; Fri, 30 Mar 2018 07:46:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1sUa-0000dr-Na for 30874@debbugs.gnu.org; Fri, 30 Mar 2018 07:46:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1sUU-0007ys-C5 for 30874@debbugs.gnu.org; Fri, 30 Mar 2018 07:46:43 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1sUN-0007ti-Ua; Fri, 30 Mar 2018 07:46:35 -0400 Original-Received: from [176.228.60.248] (port=1385 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f1sUN-0005ne-9l; Fri, 30 Mar 2018 07:46:35 -0400 In-reply-to: <87woxtq282.fsf@gmail.com> (message from Robert Pluim on Fri, 30 Mar 2018 12:36:45 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:144732 Archived-At: > From: Robert Pluim > Cc: 30874@debbugs.gnu.org, jsynacek@redhat.com > Gmane-Reply-To-List: yes > Date: Fri, 30 Mar 2018 12:36:45 +0200 > > Eli Zaretskii writes: > > >> As I understand it, we should use fontconfig for finding fonts, > >> harfbuzz for doing the layout, and cairo to actually render the > >> result > > > > Does harfbuzz require Cairo? If it does, that's unfortunate, because > > the Cairo rendering option currently has a few known and annoying > > redisplay bugs, which no one seems to be willing/capable of fixing. > > Until someone fixes > , Cairo is > basically unusable for me even without the redisplay issues. That part of cleanup_vector is under suspicion since it was born, see "git -L" reports about that function. Perhaps the easiest band-aid (or maybe it's a real fix) would be to disable this part: if (PSEUDOVECTOR_TYPEP (&vector->header, PVEC_FONT) && ((vector->header.size & PSEUDOVECTOR_SIZE_MASK) == FONT_OBJECT_MAX)) { struct font_driver const *drv = ((struct font *) vector)->driver; /* The font driver might sometimes be NULL, e.g. if Emacs was interrupted before it had time to set it up. */ if (drv) { /* Attempt to catch subtle bugs like Bug#16140. */ eassert (valid_font_driver (drv)); drv->close ((struct font *) vector); } } when the font backend is one of those which use ftfont_close. Or maybe just make ftfont_close return without doing anything if it is called from GC. > > AFAIK, there's no "fallback" per se. Whenever the already-loaded > > fonts don't support a character, Emacs looks for the fonts that do > > using the "match" method. If we always fail these fonts in that > > method, they will never be used. > > Yes, I was confused about what was happening. This explains why I was > not getting Symbola as well: that font doesnʼt have a glyph for #x274c Symbola I have installed here does have a glyph for that character, FWIW. > > I thought there could be a way of detecting those "color bitmap fonts" > > by examining their attributes in ftfont_match and/or > > ftfont_spec_pattern. Then we could return a failure indication for > > them. > > So the pattern returned from fontconfig doesnʼt indicate anything > specific we could use, but itʼs possible to modify the pattern we use > for requesting. The following patch against emacs-26 fixes the crash > for me (Emacs ends up using "Noto Emoji"). Definitely not intended to > be applied to emacs-26. > > modified src/ftfont.c > @@ -764,6 +764,8 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots > if (scalable >= 0 > && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse)) > goto err; > + /* We really don't like color fonts, they cause Xft crashes. */ > + FcPatternAddBool(pattern, FC_COLOR, FcFalse); > > goto finish; Thanks! Jan, can you see if this patch fixes the problem for you? If Jan says it does fix the problem, I think we should install this on master. What do you think about having this conditioned on a variable exposed to Lisp, as a "fire escape" in case there are some situations where users might want these fonts anyway? Also, we should probably condition this by HAVE_XFT, since AFAIU the problem is only relevant to that build?