I want to see which fonts asserts that state. please try to run with FC_DEBUG=384.

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?

Hm, okay. then can you get a stacktrace by running winecfg on gdb say?

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.

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

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."

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.

Thanks. hmm, can you reproduce it with fc-query /Library/Fonts/Skia.ttf ?

fc-query /Library/Fonts/Skia.ttf prints some information about the font, but no assertion failure message.

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.

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.

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++)
          ;

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

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)
 	{

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?

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