RFR: 8287609: macOS: SIGSEGV at [CoreFoundation] CFArrayGetCount / sun.font.CFont.getTableBytesNative

[Nikita Gubarkov]

On Tue, 31 May 2022 23:39:09 GMT, Nikita Gubarkov <duke at openjdk.java.net> wrote:

> `CTFontCopyAvailableTables` can return null, which causes subsequent call to `CFArrayGetCount` to crash with SEGFAULT, just added a null-check.

Sorry for the confusion, "maxp" being absent was only my assumption: `CTFontCopyTable` returned NULL for it, but I cannot be 100% sure about what's going on here, given that `CTFontCopyAvailableTables` doesn't even return anything.
BTW I see that `CTFontCopyAvailableTables` return type is marked as nullable, though conditions when it can be null are not specified.

So this is a very old font and I couldn't even find a tool which could edit it or at least parse and see what's inside, CoreText API is not very helpful as well. But the thing is: we can actually render this font, problems begins when we try to do a full layout, so in my opinion, adding this null-check is okay, we're just not doing anything useful in our layout code instead of crashing :).

And also if I'm not missing something, my change doesn't affect any behavior other that fixing the crash, look:
1. When I debugged it, I found around 5 or something calls to `getTableBytesNative` where it could crash, but the only table required by spec was "maxp" - I assume when asking for non-required table, callers already handle NULL case.
2. Caller uses "maxp" table to calculate upem (and falls back to 1000 if there's no such table) and set font scale (libharfbuzz/hb-font.cc:1512):

font->x_scale = font->y_scale = hb_face_get_upem (face);

3. But this scale is then overwritten anyway, so it doesn't even matter that we didn't find "maxp" table at all (libfontmanager/hb-jdk-font.cc:410):

hb_font_set_scale (font,
                  HBFloatToFixed(jdkFontInfo->ptSize*jdkFontInfo->devScale),
                  HBFloatToFixed(jdkFontInfo->ptSize*jdkFontInfo->devScale));


So it looks like there's really no behavior changed other than not crashing. In my tests text is properly rendered with `Font.layoutGlyphVector` being visually identical to `Font.createGlyphVector`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8962