Crash during font enumeration on Windows 8 64-bit

[badf00d]

Hi,

I've successfully been using Cocotron for my app on Windows XP and Windows 7 (32 and 64 bit) for the past year or so.  However, when testing the exact same app on Windows 8 RTM build (64-bit), I'm finding that it crashes on startup.

I tracked the crash down to the GDI font enumeration code in Onyx2D (O2Font_gdi.m).  The font enumeration is done in _buildNativePSmapping using EnumFontFamiliesW (to get the list of font families via EnumFamiliesCallBack) and then a loop of EnumFontFamiliesExW calls with each family (which causes EnumFontFromFamilyCallBack to be called).

For some reason, I'm seeing a font with a bad family name in EnumFamiliesCallBack (which causes the crash).  I'm able to get around this crash by limiting the font types it processes to only RASTER_FONTTYPE and TRUETYPE_FONTTYPE (i.e. skipping vector font types).  However, I'm now getting another crash on the very first EnumFontFamiliesExW call made in the loop.

I see that the callback (EnumFontFromFamilyCallBack) is happening after the call to EnumFontFamiliesExW.  However, once the callback returns, there's a crash in the GDI library somewhere (can't see the top three layers of the stack).

Has anyone else encountered this problem on Windows 8?  Any ideas/help would be appreciated.

[Christopher Lloyd]

Should be fixed in the mainline now, the callback calling convention needs to match the prototype.

Chris

[Airy André]

I opened an issue on Cocotron about it :
https://code.google.com/p/cocotron/issues/detail?id=988

with a link to a change we made on our clone which seems to fix it.

Note that we're still getting some "warning: HEAP: Free Heap block 04168478 modified at 04168490 after it was freed" messages.

Airy

> --
> You received this message because you are subscribed to the Google Groups "Cocotron Developers" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/cocotron-dev/-/QZ2vxddhWHAJ.
> To post to this group, send email to cocotr...@googlegroups.com.
> To unsubscribe from this group, send email to cocotron-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cocotron-dev?hl=en.

[Airy André]

We are just having the same problem.
If you are running with gdb, you can probably see some :

warning: HEAP: Free Heap block 04168478 modified at 04168490 after it was freed

which probably means we have some heap trashing somewhere.

If you don't plan to use Postscript names to access fonts (most fonts have the same name as the PS one), you might try to disable the PS<->win names mapping by returning in _buildNativePSmapping just after sPSToWin32Table & sWin32ToPSTable allocations.

But the message above probably means something very wrong is happening elsewhere and that crash might be a consequence of that, not the root.

Airy

Le 3 oct. 2012 à 18:34, badf00d <gord.j...@gmail.com> a écrit :

[badf00d]

Just got a chance to test the changes out and they fix the crash.  Thanks.

I'm never quite sure about all those extra specifiers in Win32 programming.  Many of them are leftovers from the computer architectures of the era (e.g. specifying pointers as near and far for 16-bit machines), so I just tend to assume they're empty on modern platforms.  I'm guessing CALLBACK is needed for visibility so that the function pointer is valid when used in a dll?

Anyways, with regard to airy's comments, I'm not seeing any heap warnings.  However, I am seeing the following message repeated a number of times in the console:

"... convertFont:toHaveTrait: failed, Arial 2"

"... convertFont:toHaveTrait: failed, Arial 4"

as well as one of these:

"*** Uncaught exception <NSInvalidArgumentException> *** -[NSMutableDictionary_CF setObject:forKey:] Attempt to insert nil object for key NSFontAttributeName"

However, my app runs fine, and the fonts look fine, so I'm assuming they're harmless.

[Airy André]

The messages means some trait conversion don't work well, because either something goes wrong with the enumeration, or some fonts are missing (like Arial Italic or Arial Bold).
I've been able to track the heap trashing. It can be easily reproduce by calling twice [NSObject performSelectorInBackground:sel object:nil] on some empty method.
I've pushed a fix our clone : https://code.google.com/r/plasqdev-cocotron/source/detail?r=9cb1529346e219a066fd8176f8d292c62956d314

The exception is a bit worrying - probably related to a missing/not found font too.
Is it coming from internal of the Framework or from your app ? (it must be coming from setting some NSAttributedString attribute, from a not found Font)

Airy

> --
> You received this message because you are subscribed to the Google Groups "Cocotron Developers" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/cocotron-dev/-/WGyuZM5i9ysJ.

[Airy André]

I could repro the font conversion problem : it can happen when you create a font with a display name (for example Arial instead of ArialMT) and then use the font manager to convert its trait.
I'll commit a fix to our clone soon.

Airy

Le 5 oct. 2012 à 06:07, badf00d <gord.j...@gmail.com> a écrit :

[Airy André]

More about the issue and a fix is available here :
https://code.google.com/p/cocotron/issues/detail?id=990

Airy

[badf00d]

Great, thanks Airy.  I'll give your changes a whirl when I get a chance.  I'll also have a look and see where that exception is coming from.  It happens on startup, so it could either be during font enumeration, or perhaps when the NIB file is being loaded.  I don't do much with fonts/attributed strings in my app as it's just a simple interface for configuring a network service, but I'll see...

[badf00d]

ok, so with those changes, I don't see those convertFont:toHaveTrait: failure messages anymore.  However, I do still get that exception.

I set a breakpoint where the exception is generated in Foundation, and I can see that it occurs when I load an RTF file into an NSTextView using readRTFDFromFile.  Going a bit deeper, the root of the problem is in processControlWithArgValue (AppKit, NSRichTextReader.m).  In a couple of places, it's trying to set a font into _currentAttributes without checking to see if it actually has a valid font.

I'm still tracking down the exact details of the font and why it ends up with a nil value there...

[badf00d]

Looks like there was a stray space character set to use Lucida Grande in my RTF file (everything else was using Helvetica).  Changing that character to be consistent with the rest of the file resolved the problem and the console is silent now.