Window 64-bit freetype backend buggy?
Closed this issue · 9 comments
Got a report which crashes only with some fonts, but successful if the freetype-based tests are switched off. This suggests a freetype backend problem. However the 32-bit build works on wine so likely
- affect only some fonts
- specific to 64-bit windows
Way to test is to switch off the 4 freetype-based tests (hdmx, vdmx, ltsh, rasterisation), to see if it stops the crashing, or use the special x86 mode only binary in https://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft%20Font%20Validator/misc/FontVal-2.1.0-py-bin-net4-x86.zip/download
Cc @DunwichType
The change to force 32-bit mode build is in the Makefile, from
EXTRA_DEV_OPTS=
to
EXTRA_DEV_OPTS=/platform:x86
The win64 backend is built with an additional patch (in reality, it is applied uniformly across all builds but has platform-detection code within to only activate itself on win64):
https://github.com/HinTak/Font-Validator/blob/master/freetype-win64-2.8.patch
It has a purpose but its robustness/correctness is somewhat questionable - and it is probably incomplete for the purpose it is intended to serve for.
The supplied test file is called fs_smi02.ttf, 7564 byte in size, md5sum 3eae16b5f0cbcd3fa57e01643e76e312 .
With LTSH, VDMX, hdmx and rasterization all switched off it runs to completion. After some more testing it runs with hdmx and rasterization ON as well but fails if either LTSH or VDMX is activated.
My system is a Windows 10 Pro 64 bit system so presumably FontVal is switching to the 64 bit backend.
One great possibility about debugging this is to run FontVal under the windows 64-bit of mono in wine.
This way one can observe both how the C# side and the C side of things changes. In particular, tracing under windows 64-bit version of mono should be useful.
This is only possible in the last 12 months or so - Mono 4.4.0 (and its dev branch 4.3.2) 08 Jun 2016 started to ship 64-bit windows version of mono.
I have managed to reproduce the crash with win64 mono (5.14) under 64-bit wine. Let's see what freetype tracing says...
It died somewhere between FT_Request_Size (truetype driver): and af_face_globals_compute_style_coverage .
It turns out the FreeType backend crashed when calling hb_ft_font_create in the autofit module. Building without harfbuzz may be a possibility.
The only two WIN64 define in harfbuzz code landed between 1.7.5 and 1.7.6, and moved between 1.8.2 and 1.8.3 . Probably need to move to 1.8.3 +
Building without harfbuzz or with rebuilt harfbuzz both work around the issue. FontVal 2.1.2 windows binaries were built with rebuilt rebuilt harfbuzz from git head.
Issue considered fixed after testing against all 3700+ fonts shipped in fedora 29, using 64-bit wine and 64-bit wine-mono .