On Thu, Jan 03, 2019 at 05:56:26PM +0100, Alexander Meyer wrote: > * Thomas Dickey <dic...@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 <dic...@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net
signature.asc
Description: Digital signature
