Bug 96609

Summary: Assertion failed: (dx > 0 && dy >= 0 && x1 <= x && x <= x2), function lerp, file fcweight.c, line 48.
Product: fontconfig Reporter: Ryan Schmidt <freedesktop>
Component: libraryAssignee: fontconfig-bugs
Status: RESOLVED DUPLICATE QA Contact: Behdad Esfahbod <freedesktop>
Severity: normal    
Priority: medium CC: akira, freedesktop
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Mac OS X (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: terminal output of running winecfg with FC_DEBUG=384
log file

Description Ryan Schmidt 2016-06-21 04:41:37 UTC
Hello, I'm the maintainer of wine and fontconfig in MacPorts.

winecfg (from wine 1.8.3 or 1.9.12) fails to launch with fontconfig 2.12.0. The error shown is:

Assertion failed: (dx > 0 && dy >= 0 && x1 <= x && x <= x2), function lerp, file fcweight.c, line 48.

This was reported to MacPorts here:

https://trac.macports.org/ticket/51674

The problem goes away if fontconfig is downgraded to 2.11.1.

P.S: Please add "2.12" to the Version selection menu in this issue tracker.
Comment 1 Akira TAGOH 2016-06-21 05:55:26 UTC
I want to see which fonts asserts that state. please try to run with FC_DEBUG=384.
Comment 2 Ryan Schmidt 2016-06-22 19:10:55 UTC
I tried running FC_DEBUG=384 winecfg and no additional information was displayed. I tried deleting the fontconfig cache and running FC_DEBUG=384 fc-cache -sv and a lot of information was displayed about the fonts it was indexing but no assertion failure occurred. Is there something else I should run to diagnose this?
Comment 3 Akira TAGOH 2016-06-23 01:33:42 UTC
Hm, okay. then can you get a stacktrace by running winecfg on gdb say?
Comment 4 Ryan Schmidt 2016-06-23 02:10:18 UTC
I have used gdb a few times, but not recently and I am not very familiar with how to use it. I cannot figure out how to run winecfg (which is a shell script, which calls wine, which is a shell script, which calls the real wine executable) in gdb.

Note that winecfg does not crash; it exits with:

err:module:attach_process_dlls "gdi32.dll" failed to initialize, aborting

OS X automatically saves logs for crashes, but since this is not a crash, it doesn't save a log.
Comment 5 Akira TAGOH 2016-06-23 02:52:15 UTC
Try:

(replace wine64 to wine if it isn't available)
$ gdb /usr/bin/wine64 winecfg.exe
(gdb) run

When the assertion happens, gdb will stop there. then

(gdb) bt
Comment 6 Ryan Schmidt 2016-06-23 03:46:19 UTC
First, I had to codesign gdb and fix its permissions and ownership so that it could control other processes:

https://sourceware.org/gdb/wiki/BuildingOnDarwin

Then, /opt/local/bin/wine is not a compiled binary in MacPorts; it is a shell script that sets DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib:/usr/lib" and then calls the compiled binary /opt/local/libexec/wine/wine with the script's arguments. wine does not work on OS X if DYLD_FALLBACK_LIBRARY_PATH is not set. gdb does not seem to want to run scripts; it only wants to run compiled binaries. I tried various ways of setting the environment variable before telling gdb to run /opt/local/libexec/wine/wine, which all failed, except when I finally created a temporary shell script /tmp/runwine with the contents:

#!/bin/sh
DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib:/usr/lib" "$@"

Then I was able to get gdb to run winecfg by running:

$ ggdb /opt/local/libexec/wine/wine
(gdb) set exec-wrapper /tmp/runwine
(gdb) run winecfg

However, gdb did not break on assertions, and running "bt" produces the message "No stack."
Comment 7 Ryan Schmidt 2016-06-23 03:54:12 UTC
Created attachment 124674 [details]
terminal output of running winecfg with FC_DEBUG=384

The wine wrapper script we use in MacPorts may be the reason why setting FC_DEBUG=384 on the command line had no effect. I added FC_DEBUG=384 to the wrapper script and did receive additional output, which looked a lot like the output I got when I ran fc-cache with FC_DEBUG=384. I've attached the compressed terminal output.
Comment 8 Akira TAGOH 2016-06-23 04:26:48 UTC
Thanks. hmm, can you reproduce it with fc-query /Library/Fonts/Skia.ttf ?
Comment 9 Ryan Schmidt 2016-06-23 09:43:31 UTC
fc-query /Library/Fonts/Skia.ttf prints some information about the font, but no assertion failure message.
Comment 10 Akira TAGOH 2016-06-23 09:57:07 UTC
Hmm, well, this is the font specific issue and I can't reproduce it here because I don't have any problematic fonts. I don't know why gdb can't catch the assertion which should usually raise SIGABRT. so the idea I have so far is only to go through every fonts with fc-query and see which fonts is raising that assertion.
Comment 11 Ryan Schmidt 2016-06-23 10:21:04 UTC
Do I need to compile fontconfig with any particular compiler flags to get assertions to trigger an abort?

I ran fc-query on every font in /Library/Fonts, /System/Library/Fonts, ~/Library/Fonts and /opt/local/share/fonts and didn't see any assertion failures.
Comment 12 Akira TAGOH 2016-06-23 10:45:55 UTC
Behdad, should FcWeightFromOpenType() fails if ot_weight is more than 999 right?

diff --git a/src/fcweight.c b/src/fcweight.c
index 1a3b608..2923c16 100644
--- a/src/fcweight.c
+++ b/src/fcweight.c
@@ -75,6 +75,8 @@ FcWeightFromOpenType (int ot_weight)
                case 9: ot_weight = 900; break;
            }
        }
+       if (ot_weight > 999)
+           return -1;
 
        for (i = 1; ot_weight > map[i].ot; i++)
          ;
Comment 13 kboo80 2016-07-01 13:41:48 UTC
Created attachment 124835 [details]
log file

hello,
I have the same problem on my mac, here is the log with FC_DEBUG=384, ontconfig@2.12.0_0+universal and wine-devel @1.9.13_0
Comment 14 Tony 2016-07-01 19:59:26 UTC
Thanks Akira for your help,

What you mentioned is correct, except it is values over 1000 instead of 999 that will trigger the assertion.

When I adjust the code and restored one line of code from a previous version it fixes the issue. Patch below:

Revert a 2.12 change in fcweight.c that introduced the bug
--- src/fcweight.c.orig	2016-07-01 14:58:33.000000000 -0400
+++ src/fcweight.c	2016-07-01 14:58:56.000000000 -0400
@@ -56,7 +56,7 @@
 
 	/* Loosely based on WPF Font Selection Model's advice. */
 
-	if (ot_weight < 0)
+	if (ot_weight < 0 || ot_weight >1000)
 	    return -1;
 	else if (1 <= ot_weight && ot_weight <= 9)
 	{
Comment 15 Ryan Schmidt 2016-07-02 05:41:47 UTC
Thanks Akira and Tony, that patch works for me and I've added it to MacPorts. Can you or someone commit it to the fontconfig repository?
Comment 16 Akira TAGOH 2016-07-04 02:38:46 UTC

*** This bug has been marked as a duplicate of bug 96676 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.