Bug 7074 - Xvnc crash with Chinese font "Simsun"
Summary: Xvnc crash with Chinese font "Simsun"
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 1.3.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.9.0
Assignee: Pierre Ossman
Keywords: hean01_tester, prosaic
Depends on:
Reported: 2017-11-01 13:21 CET by Pierre Ossman
Modified: 2017-11-06 10:05 CET (History)
2 users (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2017-11-01 13:21:34 CET
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
Comment 2 Pierre Ossman cendio 2017-11-01 15:12:59 CET
I believe I've found the issue. zlib did an ABI-breaking change back in 2011 with the 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.
Comment 4 Pierre Ossman cendio 2017-11-02 12:46:35 CET
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.
Comment 5 Pierre Ossman cendio 2017-11-02 15:51:19 CET
The conditions that trigger this are currently unclear or random so a descriptive release note will be difficult.
Comment 6 Henrik Andersson cendio 2017-11-06 09:03:32 CET
Reproduced the original crash using RHEL6 and xfontsel, then upgraded and verified that the font is rendered perfectly fine.
Comment 7 Henrik Andersson cendio 2017-11-06 09:08:01 CET
With the update on a RHEL6 platform, I played around with other X11 core fonts and couldn't find any problems.
Comment 8 Henrik Andersson cendio 2017-11-06 10:05:48 CET
Tested X11 core fonts on Fedora 25, no problems found.

Note You need to log in before you can comment on or make changes to this bug.