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) > (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) > (EE) Segmentation fault at address 0x7f6400003ff6
I believe I've found the issue. zlib did an ABI-breaking change back in 2011 with the 1.2.5.2 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.
