Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Thu, Jan 03, 2019 at 05:56:26PM +0100, Alexander Meyer wrote:
> * Thomas Dickey <dickey at his.com> [2019-01-02 10:46]:
> 
> > I verified that the same issue exists in current code, and submitted an
> > 
> > 	https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/140
> > 
> > with the attached fix.
> 
> As a side note, visiting that particular page causes both Chromium and
> Firefox to crash in a manner that looks similar to what I reported for
> xterm. Chromium crashes completely, in Firefox it's just a tab crash.

perhaps the bug will get more attention then :-)
 
> As with the xterm issue, this doesn't occur when I remove either my
> fonts.conf file or the package fonts-noto-color-emoji.
> 
> These two characters appear on the page:
> 
> U+1F44D THUMBS UP SIGN
> U+1F44E THUMBS DOWN SIGN
> 
> And the CSS stylesheet seems to load the "Noto Color Emoji" font.

The fontconfig debug-trace can verify that
(setting the environment variable FC_DEBUG to 1 gives a trace
which shows the filename along with other details - much more than XFT_DEBUG=3).
 
> In Firefox, the crash doesn't happen when I remove the two offending
> characters from the page source /or/ when I remove the CSS file. In
> Chromium, only removing the CSS file helps.
> 
> So it seems that more packages might be affected? But it's probably best
> to wait for the provided patch to make it into fontconfig before taking
> more time to look into this?
> 
> For the record, here's the crash report from Firefox (probably not
> particularly useful due to missing symbols):
> https://crash-stats.mozilla.com/report/index/afb14dec-e1f6-43dd-8852-d80670190103
> 
> And this is what Chromium outputs on the terminal:
> 
> Received signal 11 SEGV_MAPERR 000000000000
> #0 0x55ed814cc9d1 <unknown>
> #1 0x55ed814cb413 <unknown>
> #2 0x55ed814cc945 <unknown>
> #3 0x7f59461f86b0 <unknown>
> #4 0x7f5942b5c2d1 <unknown>
> #5 0x7f5942b5c418 <unknown>
> #6 0x7f5942b5d55f FcConfigSubstituteWithPat
> #7 0x7f5942b6d9bd FcFontRenderPrepare
> #8 0x7f5942b6de44 FcFontMatch

That's a different path, but still in the same file.

Actually when I looked into this, I expected to spend more time finding
a good solution, but adding the simple fix made the problem go away.

There are 250/2714 lines in fccfg.h using pointers and the instance here
dated from April 2012, so there's the potential for several similar bugs.

-- 
Thomas E. Dickey <dickey at invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-freedesktop-maintainers/attachments/20190103/96ca0c8e/attachment-0001.sig>