Bugzilla – Bug 7074
Xvnc crash with Chinese font "Simsun"
Last modified: 2017-11-06 10:05:48
You need to
before you can comment on or make changes to this bug.
This is a continuation of bug 7025. Apparently more issues exist.
We've done the following steps as root on RHEL 6:
> # yum groupinstall "Chinese Support"
> # mkdir /usr/share/fonts/local
> # cp simsun.ttc /usr/share/fonts/local
> # cd /etc/X11/fontpath.d
> # ln -s /usr/share/fonts/local ./local
> # cd /usr/share/fonts/local
> # mkfontscale -e /usr/share/X11/fonts/encodings/large
> # ttmkfdir -e ./encodings.dir
> # copy fonts.scale fonts.dir
> # fc-cache
After that we started a thinlinc session and ran xfontsel. Xvnc then
immediately crashed with:
> (EE) Backtrace:
> (EE) 0: /opt/thinlinc/libexec/Xvnc (xorg_backtrace+0x3f) [0x5e258f]
> (EE) 1: /opt/thinlinc/libexec/Xvnc (0x400000+0x1e5a19) [0x5e5a19]
> (EE) 2: /lib64/libpthread.so.0 (0x7f64e456b000+0xf7e0) [0x7f64e457a7e0]
> (EE) 3: /opt/thinlinc/libexec/Xvnc (0x400000+0x25aee8) [0x65aee8]
> (EE) 4: /opt/thinlinc/libexec/Xvnc (0x400000+0x25b612) [0x65b612]
> (EE) 5: /opt/thinlinc/libexec/Xvnc (0x400000+0x25c23c) [0x65c23c]
> (EE) 6: /opt/thinlinc/libexec/Xvnc (FontEncReallyLoad+0xce) [0x65c3fe]
> (EE) 7: /opt/thinlinc/libexec/Xvnc (FontEncFind+0x70) [0x65a6d0]
> (EE) 8: /opt/thinlinc/libexec/Xvnc (FTPickMapping+0xc9) [0x652679]
> (EE) 9: /opt/thinlinc/libexec/Xvnc (0x400000+0x238363) [0x638363]
> (EE) 10: /opt/thinlinc/libexec/Xvnc (0x400000+0x23c0e6) [0x63c0e6]
> (EE) 11: /opt/thinlinc/libexec/Xvnc (0x400000+0x23ed1b) [0x63ed1b]
> (EE) 12: /opt/thinlinc/libexec/Xvnc (0x400000+0x250eb5) [0x650eb5]
> (EE) 13: /opt/thinlinc/libexec/Xvnc (FontFileListNextFontWithInfo+0x53) [0x650f53]
> (EE) 14: /opt/thinlinc/libexec/Xvnc (0x400000+0x24d4c5) [0x64d4c5]
> (EE) 15: /opt/thinlinc/libexec/Xvnc (doListFontsWithInfo+0x17b) [0x594e7b]
> (EE) 16: /opt/thinlinc/libexec/Xvnc (StartListFontsWithInfo+0x163) [0x596f13]
> (EE) 17: /opt/thinlinc/libexec/Xvnc (Dispatch+0x28f) [0x593a6f]
> (EE) 18: /opt/thinlinc/libexec/Xvnc (main+0x3ae) [0x4a7cee]
> (EE) 19: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f64e41f1d1d]
> (EE) 20: /opt/thinlinc/libexec/Xvnc (0x400000+0xa96c3) [0x4a96c3]
> (EE) Segmentation fault at address 0x7f6400003ff6
I believe I've found the issue. zlib did an ABI-breaking change back in 2011
with the 188.8.131.52 release where gzgetc() was changed from a function to a macro.
So any software built against a newer zlib will explode if run on a system with
an older zlib.
Fortunately libfontenc is the only software I can find in our build system that
uses gzgetc(), so only that is affected. And we introduced the problem in to
our binaries back in late 2014.
Crash is now gone under the scenario in the initial description. I also checked
that other fonts rendered sanely in xfontsel on RHEL 6 and RHEL 7.
Tester might want to check the original scenario, and core fonts on some other
distribution. Not sure of any good test applicatione except xfontsel though.
The conditions that trigger this are currently unclear or random so a
descriptive release note will be difficult.
Reproduced the original crash using RHEL6 and xfontsel, then upgraded and
verified that the font is rendered perfectly fine.
With the update on a RHEL6 platform, I played around with other X11 core fonts
and couldn't find any problems.
Tested X11 core fonts on Fedora 25, no problems found.