Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
* Thomas Dickey [2019-01-04 01:10]: > On Thu, Jan 03, 2019 at 05:56:26PM +0100, Alexander Meyer wrote: >> * Thomas Dickey [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 :-) Would this warrant to add "affects" tags for firefox and chromium to this bug? Not sure about the Debian policy here. In this case, the Subject line should probably be changed to something more meaningful. >> 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). Thanks, this looks useful. In Chromium, it shows that /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf is loaded when fonts-noto-color-emoji is installed and I visit the page, both with fonts.conf enabled and disabled. I cannot discern, though, which effect from fonts.conf triggers the bug. In Firefox, though, there's no mention of NotoColorEmoji.ttf in the output!? >> 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 >> #0 0x55ed814cc9d1 >> #1 0x55ed814cb413 >> #2 0x55ed814cc945 >> #3 0x7f59461f86b0 >> #4 0x7f5942b5c2d1 >> #5 0x7f5942b5c418 >> #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. Running /usr/bin/chromium with the "-g" option and chromium-dbgsym installed reveals that the crash is on the same line. See the trace below. If anybody knows how I can get a tab crash report from Firefox with debug symbols, I could verify that, too. # Env: # LD_LIBRARY_PATH= # PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/local/bin:/usr/local/graphviz-2.14/bin:/home/alex/bin:/opt/local/libexec/perl5.12/sitebin:/usr/local/bin:/usr/local/graphviz-2.14/bin:/home/alex/bin:/opt/local/libexec/perl5.12/sitebin #GTK_PATH= # CHROMIUM_FLAGS= --show-component-extension-options --ignore-gpu-blacklist --no-default-browser-check --disable-pings --media-router=0 --enable-remote-extensions --load-extension= /usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.CtrzY4 GNU gdb (Debian 8.2-1) 8.2 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
* Thomas Dickey [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. 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. 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 #0 0x55ed814cc9d1 #1 0x55ed814cb413 #2 0x55ed814cc945 #3 0x7f59461f86b0 #4 0x7f5942b5c2d1 #5 0x7f5942b5c418 #6 0x7f5942b5d55f FcConfigSubstituteWithPat #7 0x7f5942b6d9bd FcFontRenderPrepare #8 0x7f5942b6de44 FcFontMatch #9 0x55ed81b8ec63 #10 0x55ed8032726f #11 0x55ed7f794bdc #12 0x55ed80326c5c #13 0x55ed8151395b #14 0x55ed81516204 #15 0x55ed81517363 #16 0x55ed81511ba0 #17 0x55ed81511e8a #18 0x55ed8152177f #19 0x55ed8141925d #20 0x55ed81496f61 #21 0x55ed814e1e57 #22 0x55ed814994c3 #23 0x55ed814908b6 #24 0x55ed81490d84 #25 0x55ed814dcec5 #26 0x7f59461edfa3 start_thread #27 0x7f593def988f clone r8: 7f5900177110 r9: 7f5900177110 r10: 0003 r11: 0020 r12: 55ed88462528 r13: 7f590002cad0 r14: 7f59000690a0 r15: 0001 di: 7f590002cad0 si: 7f59000690a0 bp: 55ed88312ba0 bx: 0003 dx: 0001 ax: 55ed88312b70 cx: sp: 7f590f7fbb40 ip: 7f5942b5c2d1 efl: 00010202 cgf: 002b0033 erf: 0004 trp: 000e msk: cr2: [end of stack trace] Calling _exit(1). Core file will not be generated.
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
* Thomas Dickey [2018-12-31 20:32]: > On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote: >> * Thomas Dickey [2018-12-31 00:51]: >> >>> Can you make a backtrace for #341, please? >> >> Here it is: [...] Thanks a lot for taking the time to investigate the issue and for providing the fontconfig patch! I've been away from home and couldn't reply earlier. As the issue has now been solved xterm-wise, just a few remarks: >> Reading symbols from /usr/bin/xterm...Reading symbols from >> /usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done. >> done. >> (gdb) run -fa 'Noto Mono' > > fwiw, my Debian/testing machine has these fonts (with "noto" in their names): > > ii fonts-noto20181130-1 > all metapackage to pull in all Noto fonts > ii fonts-noto-cjk1:20170601+repack1-3 > all "No Tofu" font families with large Unicode coverage > (CJK regular and bold) > ii fonts-noto-color-emoji0~20180810-1 > all color emoji font from Google > ii fonts-noto-hinted 20181130-1 > all "No Tofu" font families with large Unicode coverage > (hinted) > ii fonts-noto-mono 20181130-1 > all "No Tofu" monospaced font family with large Unicode > coverage > ii fonts-noto-unhinted 20181130-1 > all "No Tofu" font families with large Unicode coverage > (unhinted) Exactly the same on my system. fonts-noto-color-emoji was only recently installed via a dependency at the same time as xterm was upgraded from 337 to 338. It turns out that simply removing the package fonts-noto-color-emoji eliminates the issue! So that's probably the best workaround right now for anyone with the same problem, until your patch is incorporated into fontconfig. [...] > This part is in the newer function which handles fallback fonts. > Since your trace shows line-numbers, I'm assuming it's not the Debian package. > (Actually the trace seems to show that you've compiled fontconfig -- turning > off the optimization might help pinpoint the details). For the record, no, the trace had been made with the provided xterm-dbgsym and libfontconfig1-dbgsym packages. Best Alex
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
* Thomas Dickey [2018-12-31 00:51]:
> On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> ...
>> This is the behaviour I get across xterm versions:
>> (everything with libfontconfig1 2.13.1-2)
>>
>> fonts.conf enabled:
>> 337: works
>> 338: segfault
>> 340: segfault
>> 341: segfault
>
> Can you make a backtrace for #341, please?
Here it is:
Reading symbols from /usr/bin/xterm...Reading symbols from
/usr/lib/debug/.build-id/b8/d462fb6f4969a6a228262ceff981af02a1a4d5.debug...done.
done.
(gdb) run -fa 'Noto Mono'
Starting program: /usr/bin/xterm -fa 'Noto Mono'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x77d662d1 in FcConfigEvaluate (p=0x556f2430, p_pat=0x559dea90,
kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
(gdb) bt full
#0 0x77d662d1 in FcConfigEvaluate (p=0x556f2430,
p_pat=0x559dea90, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
v = {type = FcTypeVoid, u = {s = 0x556f1ad0 " \033oUUU", i =
1433344720, b = 1433344720, d = 4.6355706220021174e-310, m = 0x556f1ad0, c
= 0x556f1ad0, f = 0x556f1ad0,
l = 0x556f1ad0, r = 0x556f1ad0}}
vl = {type = 1433014944, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vr = {type = 1436412560, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, c
= 0x0, f = 0x0, l = 0x0, r = 0x0}}
vle =
vre =
m =
str =
op =
buf1 = {u = {d = 0, i = 0, l = 0,
c =
"\000\000\000\000\000\000\000\000\200\032oUUU\000\000\270\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
'\000' ,
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\060\032oUUU\000\000\320\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
'\000' ,
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\340\031oUUU\000\000\350\022jUUU\000\000\000\000\000\000\000\000\000\000\220\352\235UUU",
'\000' ,
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
buf2 = {u = {d = 0, i = 0, l = 0,
c =
"\000\000\000\000\000\000\000\000@\031oUUU\000\000\030\023jUUU\000\000\000\000\000\000\000\000\000\000\025",
'\000' , "\a\000\000\000\000\000\000\000
\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
'\000' , "[\000\000\000w", '\000' ,
"n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
'\000' , "\260\377\377\377\377\377\377\377"...}}
#1 0x77d66418 in FcConfigEvaluate (p=p@entry=0x556f2430,
p_pat=p_pat@entry=0x559dea90, kind=kind@entry=FcMatchFont,
e=e@entry=0x55681218) at fccfg.c:1003
m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, yx =
1.4821969375237396e-323, yy = 1}
xx =
yy =
xy =
yx =
v = {type = FcTypeMatrix, u = {s = 0x3 , i = 3, b = 3, d = 1.4821969375237396e-323, m = 0x3, c = 0x3, f =
0x3, l = 0x3, r = 0x3}}
vl = {type = FcTypeVoid, u = {s = 0x556f24b0 "Noto Color Emoji", i
= 1433347248, b = 1433347248, d = 4.6355706221270172e-310, m = 0x556f24b0,
c = 0x556f24b0, f = 0x556f24b0,
l = 0x556f24b0, r = 0x556f24b0}}
vr = {type = FcTypeString, u = {s = 0x77d660a4
"\205\300\017\224\300\017\266\300\351\267\375\377\377L\211\346H\211\327\350\364=",
i = -136945500, b = -136945500,
d = 6.9533490418283141e-310, m = 0x77d660a4
, c = 0x77d660a4 , f =
0x77d660a4 ,
l = 0x77d660a4 , r = 0x77d660a4
}}
vle =
vre =
m =
str =
op = FcOpMatrix
buf1 = {u = {d = 4.6355706048940074e-310, i = 1432998448, l =
93824993579568,
c =
"0\322iUUU\000\000\002\000\000\000\000\000\000\000\060\026jUUU\000\000\354c\326\367\377\177\000\000\000\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\003",
'\000' , "\a\000\000\000\000\000\000\000
\000\000\000\000\000\000\000\002\000\000\000UU\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
'\000' ,
"\f\341\327\367\377\177\000\000\000\000\000\000\257\060\000\000\000\240\316\365\301\035?\376\003\000\000\000\000\000\000\000\256\340\327\367\377\177\000\000\200\326\377\377\264\060\000\000\000"...}}
buf2 = {u = {d = 4.6355706320533889e-310, i = 1433
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
* Thomas Dickey [2018-12-30 23:14]: > On Sun, Dec 30, 2018 at 10:15:53PM +0100, Sven Joachim wrote: >> On 2018-12-30 18:26 +0100, Alexander Meyer wrote: >>> So the segfault only happens with that fonts.conf. >> >> Thanks, that explains why others did not see it - and possibly also why >> I could still reproduce #916349 in xterm 340, as I have my own >> fonts.conf, albeit a much shorter and simpler one than yours. >> >> Alas, with your file (saved as /tmp/fonts.conf) xterm does not even start >> here, although I have fonts-noto-mono and fonts-noto-color-emoji >> installed: > > If xterm sees the latter, it will not start. That's a problem that can > only be solved by modifying Xft. Not xterm. > > But the short term goal is to get xterm working as well as feasible with > Xft before moving on to see what can be done to make Xft handle the > color bitmap fonts. > > I'm looking for details on how to reproduce the segmentation violation > which was reported. > >> , >> | $ FONTCONFIG_FILE=/tmp/foo/fonts.conf xterm -fa 'Noto Mono' > > Back up a step: with that fonts.conf, I get no result for > fc-match 'Noto Mono' > > while without it, I do get a match. A quick look at strace tells me > that setting FONTCONFIG_FILE eliminates a lot of the normal configuration > information, and probably isn't what you want to do in reproducing the > problem. For the record: I disabled/enabled my fonts.conf by moving it out of ~/.config/fontconfig/ and then back inside. I did not set FONTCONFIG_FILE. Also, as described in my original report, the segfault is not limited to "Noto Mono" but seems to happen with any other font, too. (I've randomly tried a few from my fc-list.) >> | xterm: cannot match normal font "Noto Mono" >> | xterm: Selected font has no non-zero height for ISO-8859-1 encoding > > ...and because there's no match, for _this_ case I get the same failure. > > However, that's not a bug (in xterm), but a problem with configuration. > >> So I am a bit at a loss here. And I am definitely not a an expert on >> fontconfig (or fonts in general) either. > > I'd like to see the XFT_DEBUG information from the known broken scenario. > If it tells me that Xft is still loading the color-noto font, there's > probably nothing that I can do to address that in xterm. Please find attached the gzipped output of $ XFT_DEBUG=1023 xterm -fa 'Noto Mono' with xterm 341. All output happens directly after startup, there's no output after issuing the command that displays the character that causes the segfault. Best Alex xterm-341-XFT_DEBUG_1023.log.gz Description: application/gzip
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
* Sven Joachim [2018-12-29 19:20]: > On 2018-12-21 20:54 +0100, Alexander Meyer wrote: > >> * Sven Joachim [2018-12-21 20:38]: >> >>> On 2018-12-21 20:16 +0100, Alexander Meyer wrote: >>> >>>> I've found a bug report from Arch Linux that looks similar: >>>> https://bugs.archlinux.org/task/61115 [...] >>> I could also still reproduce it, that's why I did not close #916349 in >>> the xterm 340-1 upload. >> >> I couldn't tell whether that bug was the same as mine, as none of the >> error messages mentioned there came up for me, also that bug doesn't >> talk about segfaulting. > > Oh, indeed. But neither does the Archlinux bug report, it only mentions > the dreadful "X Error of failed request" which aborts xterm. That's right, indeed. Maybe mentioning the Arch Linux report caused confusion rather than it helped. I'm sorry. > And I could reproduce that with xterm 338 trough 340, but not your > segfault. > >> If you think this is the same bug, then feel free to merge, of course. > > If you still get a segfault in xterm 341 (uploaded today), please tell > me and I will unmerge and reopen your bug. Unfortunately, I still get the same segfault with 341. But I've just noticed that the behaviour changes depending on whether I have a fonts.conf file enabled or not. I normally use the fonts.conf file from https://gist.github.com/dcrystalj/d1c1ceacf0d6fc9a0556 installed in ~/.config/fontconfig/fonts.conf This is the behaviour I get across xterm versions: (everything with libfontconfig1 2.13.1-2) fonts.conf enabled: 337: works 338: segfault 340: segfault 341: segfault fonts.conf disabled: 337: works 338: aborts with error message "BadLength (poly request too large or internal Xlib length error)" as described in bug 916349 340: works! (as opposed to what is reported in bug 916349) 341: works So the segfault only happens with that fonts.conf. To be honest, I know next to nothing about fontconfig or font handling in X. I've installed that file some years ago without knowing what it actually does because it made some fonts look nicer in Firefox etc. and happened to have no ill side effects until now. Maybe I could even get along without it, but that wouldn't resolve this bug, of course. Best Alex
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
* Sven Joachim [2018-12-21 20:38]: > On 2018-12-21 20:16 +0100, Alexander Meyer wrote: > >> Package: xterm >> Version: 340-1 >> Severity: important >> [...] >> I've found a bug report from Arch Linux that looks similar: >> https://bugs.archlinux.org/task/61115 > > Strange that you looked in the Arch bugtracker, but apparently not in > the Debian BTS… That came up via a web search as I had originally thought the bug had to do with mutt. >> But the last comment there claims the bug disappeared in 340 which is not the >> case for me. > > I could also still reproduce it, that's why I did not close #916349 in > the xterm 340-1 upload. I couldn't tell whether that bug was the same as mine, as none of the error messages mentioned there came up for me, also that bug doesn't talk about segfaulting. If you think this is the same bug, then feel free to merge, of course. Thanks Alex
Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa
Package: xterm
Version: 340-1
Severity: important
Dear Maintainer,
after updating from 337-1 to 338-1 in testing, xterm crashes with a segfault
when certain Unicode characters appear in the buffer. This only happens when I
have selected a font using the -fa option. It doesn't seem to matter which font
it is. (I've randomly tried a few from my fc-list.)
I've installed 340-1 from unstable, but the bug persists.
As I came across this issue while reading mails in mutt, I've tried to identify
the exact characters causing it. It turned out that these commands cause the
crash:
$ /usr/bin/printf "\U0001F384"# U+1F384 CHRISTMAS TREE
$ /usr/bin/printf "\U0001F385"# U+1F385 FATHER CHRISTMAS
$ /usr/bin/printf "\U0001F3E1"# U+1F3E1 HOUSE WITH GARDEN
$ /usr/bin/printf "\U0001F644"# U+1F644 FACE WITH ROLLING EYES
Whereas these commands work fine:
$ /usr/bin/printf "\U0001F601"# U+1F601 GRINNING FACE WITH SMILING EYES
$ /usr/bin/printf "\U0001F604"# U+1F604 SMILING FACE WITH OPEN MOUTH
AND SMILING EYES
To reproduce this bug, run one of the aforementioned commands after starting
xterm with e.g.
$ xterm -fa 'Noto Mono'
When leaving out -fa, xterm doesn't crash.
Please find below a backtrace.
As the bug was introduced after updating xterm (libfontconfig1 remained
untouched during that update), I'm filing this under xterm for the time being.
xterm 337-1 doesn't crash. Interestingly, though, in 337-1 all six
above-mentioned characters are not displayed at all when running with e.g.
-fa 'Noto Mono'. I just see a two-glyph-wide blank space. Whereas in 338-1 and
340-1, the two non-crashing characters U+1F601 and U+1F604 are actually
displayed.
I've found a bug report from Arch Linux that looks similar:
https://bugs.archlinux.org/task/61115
But the last comment there claims the bug disappeared in 340 which is not the
case for me.
I don't know a great deal about X font handling, so in case you need more info,
please try to explain in detail what you need to know. Thanks in advance. Also,
I don't care that much if those special glyphs are actually displayed correctly
in my xterm or not, it's just that xterm shouldn't crash.
Backtrace:
Reading symbols from /usr/bin/xterm...Reading symbols from
/usr/lib/debug/.build-id/e1/82f855c9d3aa8701e44c1fc1d41e81eb0b0bd6.debug...done.
done.
(gdb) run -fa 'Noto Mono'
Starting program: /usr/bin/xterm -fa 'Noto Mono'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x77d662d1 in FcConfigEvaluate (p=0x556fdfd0,
p_pat=0x559ea680, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
(gdb) bt full
#0 0x77d662d1 in FcConfigEvaluate (p=0x556fdfd0,
p_pat=0x559ea680, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
v = {type = FcTypeVoid, u = {s = 0x556fd670 "\300\326oUUU",
i = 1433392752, b = 1433392752, d = 4.6355706243752135e-310,
m = 0x556fd670, c = 0x556fd670, f = 0x556fd670,
l = 0x556fd670, r = 0x556fd670}}
vl = {type = 1433007920, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0,
c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
vr = {type = 1436460672, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0,
c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
vle =
vre =
m =
str =
op =
buf1 = {u = {d = 0, i = 0, l = 0,
c = "\000\000\000\000\000\000\000\000
\326oUUU\000\000H\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
'\000' ,
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\320\325oUUU\000\000`\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
'\000' ,
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\200\325oUUU\000\000x\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
'\000' ,
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
buf2 = {u = {d = 0, i = 0, l = 0,
c =
"\000\000\000\000\000\000\000\000\340\324oUUU\000\000\250\367iUUU\000\000\000\000\000\000\000\000\000\000\025",
'\000' , "\a\000\000\000\000\000\000\000
\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
'\000' , "[\000\000\000w", '\000' ,
"n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
'\000' , "\260\377\377\377\377\377\377\377"...}}
#1 0x77d66418 in FcConfigEvaluate (p=p@entry=0x556fdfd0,
p_pat=p_pat@entry=0x559ea680, kind=kind@entry=FcMatchFont,
e=e@entry=0x55683b38) at fccfg.c:1003
m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310,
yx =
