Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
dickey at his.com
Fri Jan 4 00:10:56 GMT 2019
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):
> 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the Pkg-freedesktop-maintainers