[wxFont] Crash in constructor only on MacOs 10.15.7

[Filip Sykala]

In application I serialize and deserialize font descriptors by functions:
serialization by: wxFont::GetNativeFontInfoDesc()
deserialization by constructor: wxFont::wxFont(const wxString &nativeInfoString)

During log of the descriptors it was multiple times this:
3;90;0;0;43;<plist version="1.0"><dict><key>NSCTFontTraitsAttribute</key><dict><key>NSCTFontProportionTrait</key><real>0.0</real><key>NSCTFontWeightTrait</key><real>0.0</real></dict><key>NSFontFamilyAttribute</key><string>Helvetica</string><key>NSFontSizeAttribute</key><real>13</real></dict></plist>

but than once wxFont give me different descriptor
1;14;72;90;400;0;0;Helvetica;43
and next loading of the previous generated descriptor, which I multiple time before load correctly, now cause the crash.

By my searching in wxWidget sources:
- first number in descriptor should be version of serialization.

So ... something cause that wxFont use older way to serialize.
And it seems that after this change it do not accept newer(version 3) descriptor to deserialize.

I don't have machine for reproduce the crash.
It is not only one person with this issue but at this moment all of them has MacOS with version 10.15.7
I can confirm the crash not appear on latest macOS Big Sur 11.7.4 neither window or Linux.

CrashLog:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==35913==ERROR: AddressSanitizer: SEGV on unknown address 0x7fff198009d8 (pc 0x7fff6737ae5d bp 0x7ffeed3c6570 sp 0x7ffeed3c6538 T0)
==35913==The signal is caused by a READ memory access.
    #0 0x7fff6737ae5d in objc_msgSend+0x1d (libobjc.A.dylib:x86_64+0x5e5d)
    #1 0x7fff6830bd2b in cache_get+0x7f (libcache.dylib:x86_64+0x2d2b)
    #2 0x7fff2e7c9573 in -[NSCache objectForKey:]+0xa2 (CoreFoundation:x86_64+0x5f573)
    #3 0x7fff305f101d in TPurgeableCache::RetainedValueForKey(void const*)+0x35 (CoreText:x86_64+0x601d)
    #4 0x7fff305f0d78 in TDescriptorSource::CopyDescriptorUncached(__CFURL const*, bool, __CFString const*) const+0x36 (CoreText:x86_64+0x5d78)
    #5 0x7fff305f0d00 in TDescriptorSource::CopyDescriptor(__CFURL const*, bool, __CFString const*) const+0x26 (CoreText:x86_64+0x5d00)
    #6 0x7fff306508c7 in TDescriptorSource::CopyCachedDescriptors(__CFDictionary const*, unsigned long, TCFRef<__CFArray const*>&, CFComparisonResult (*)(void const*, void const*, void*), void*) const+0x1ed (CoreText:x86_64+0x658c7)
    #7 0x7fff3064fcd9 in TDescriptorSource::CopyDescriptorsForRequest(__CFDictionary const*, __CFSet const*, CFComparisonResult (*)(void const*, void const*, void*), void*, unsigned long, TCFRef<__CFArray const*>*) const+0x10d (CoreText:x86_64+0x64cd9)
    #8 0x7fff30659da3 in TDescriptorSource::CopyDescriptorForRequest(__CFDictionary const*, __CFSet const*, CFComparisonResult (*)(void const*, void const*, void*), void*, unsigned long) const+0x6d (CoreText:x86_64+0x6eda3)
    #9 0x7fff305ef6b7 in TDescriptor::CreateMatchingDescriptorInternal(__CFSet const*, unsigned long) const+0x51d (CoreText:x86_64+0x46b7)
    #10 0x7fff30602f12 in TDescriptor::InitBaseFont(unsigned long, double)+0x3c (CoreText:x86_64+0x17f12)
    #11 0x7fff305f242e in TDescriptor::CopyAttribute(__CFString const*) const+0xae (CoreText:x86_64+0x742e)
    #12 0x7fff305f233f in CTFontDescriptorCopyAttribute+0x64 (CoreText:x86_64+0x733f)
    #13 0x1085219e7 in wxNativeFontInfo::GetPostScriptName() const+0x87 (PrusaSlicer:x86_64+0x105cf39e7)
    #14 0x108520f03 in wxFontRefData::Alloc()+0x53 (PrusaSlicer:x86_64+0x105cf2f03)
    #15 0x108523667 in wxFont::RealizeResource()+0x27 (PrusaSlicer:x86_64+0x105cf5667)
    #16 0x108522692 in wxFont::wxFont(wxString const&)+0x102 (PrusaSlicer:x86_64+0x105cf4692)
    #17 0x10627cd8d in Slic3r::GUI::WxFontUtils::load_wxFont(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)+0x72d (PrusaSlicer:x86_64+0x103a4ed8d)


More info in Github issue:
[MacOS] Crash when change embossed text size · Issue #9538 · prusa3d/PrusaSlicer (github.com)

[Stefan Csomor]

Hi

 

Which wx version is this ?

 

The crash occurs inside macOS so something we ask for is not ok, either from the params, or something is wrong within the system …

1;14;72;90;400;0;0;Helvetica;43

this means a proper font was not obtainable from the system, then version 1 is used, but actually this should not happen for Helvetica, so the question is how has this font been constructed

 

size 14, font family ROMAN – and at the same time Name Helvetica (which would be family SWISS) ? style Normal, weight Normal, UTF8 encoding

 

perhaps there is something left behind …

 

also:

 

[2023-02-04 10:16:47.924907] [0x000000011b7e5dc0] [error]   Can not process font('Helvetica'), file in path('/System/Library/Fonts/Helvetica.ttc#postscript-name=Helvetica') is not valid TTF.

 

is an indication about something not ok about Helvetica, this might also be an explication. I’ve also had problems with strange Helvetica, does font book show something special about this font on these machines ?

 

and - in the movie the font size field is empty at one moment, you are not creating a font of size 0, are you ?

 

Perhaps it’s the coincidence of two problems at the same time, that cause the crash ?

 

Best,

 

Stefan

[Filip Sykala]

Thanks Stefan, for your reaction.

Which wx version is this ?

wxWidgets 3.2.0

something we ask for is not ok

Which value from wxFont should I log?

how has this font been constructed

from native font descriptor:  

3;90;0;0;43;<plist version="1.0"><dict><key>NSCTFontTraitsAttribute</key><dict><key>NSCTFontProportionTrait</key><real>0.0</real><key>NSCTFontWeightTrait</key><real>0.0</real></dict><key>NSFontFamilyAttribute</key><string>Helvetica</string><key>NSFontSizeAttribute</key><real>13</real></dict></plist>

and then call function
wxFont::SetPointSize()

BTW message:  Can not process font('Helvetica'), file in path('/System/Library/Fonts/Helvetica.ttc#postscript-name=Helvetica') is not valid TTF.
Is made by me because I only badly handle the uri. I already fixed it and it is not the source of the crash.

does font book show something special about this font on these machines ?

I don't know how to check it. You could ask for the font on github.

 

and - in the movie the font size field is empty at one moment, you are not creating a font of size 0, are you ?

Good point to investigate. I am not 100% sure. But In my opinion in this case it was NOT zero.

NOTE: Crash not appear during set wxFont point size event when serializing this wxFont. But during the deserialization of the correct descriptor.

Perhaps it’s the coincidence of two problems at the same time, that cause the crash ?

NOTE: Crash and all work with wxFont is on the Main thread.

Dne středa 1. března 2023 v 18:18:14 UTC+1 uživatel Stefan Csomor napsal:

[Vojtěch Bubník]

Stephan, 

thanks for looking into this issue. 

I peeked into the wxWidgets source code and frankly I see nothing suspicious, however I am not really skilled in NextStep toolkit. I only guess that maybe there could be a reference counting issue and some of the NextStep objects are used after release?

Indeed the crash only happens inside the NextStep (macOS) libraries and on one particular macOS version, thus the issue is difficult to debug and we don't have access to that particular OS version. We are considering getting that macOS version virtualized, however if we push it forward, it will take us some time.

Vojtech

--
Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/de3c55c4-cd79-4835-bc95-bf1433da6d96n%40googlegroups.com.

[Stefan Csomor]

Hi Vojtech

 

thanks for looking into this issue. 

you are welcome 😊

I peeked into the wxWidgets source code and frankly I see nothing suspicious, however I am not really skilled in NextStep toolkit. I only guess that maybe there could be a reference counting issue and some of the NextStep objects are used after release?

 

That might be, or some other situation that leads to a macOS internal problem on 10.15, but since it’s wx that’s triggering it, we should at least be able to find out why and what, to be able to guard it somehow, or provide clear user instructions, in the case of a font problem.

 

Indeed the crash only happens inside the NextStep (macOS) libraries and on one particular macOS version, thus the issue is difficult to debug and we don't have access to that particular OS version. We are considering getting that macOS version virtualized, however if we push it forward, it will take us some time.

 

I have access to a Catalina System, I’ll restart my mac mini on that and try to reproduce it as well

 

To me this sequence from @dupoxy s log from yesterday might be the reason a v1 serialization string is produced, and this somehow destabilizes things, since Filip has already produced a fix for that, let’s hope that this cures things, we’ll see …

 

Is this on all 10.15 computers, or only on some ?

 

Best,

 

Stefan

 

[2023-02-28 18:03:58.135199] [0x000000010d9eadc0] [trace]   input uri(file:///System/Library/Fonts/Helvetica.ttc#postscript-name=Helvetica) convert to path(/System/Library/Fonts/Helvetica.ttc) string(/System/Library/Fonts/Helvetica.ttc).

[2023-02-28 18:03:58.166689] [0x000000010d9eadc0] [info]    Undo / Redo snapshot taken: Text: Embossed text, Undo / Redo stack memory: 1MB Resident memory: 1,355MB; Peak memory usage: 1,380MB

[2023-02-28 18:03:58.192454] [0x000000010d9eadc0] [info]    Same FontNames hash, cache is used. For clear cache delete file: /Users/dup/Library/Application Support/PrusaSlicer-alpha/cache/fonts.cereal

[2023-02-28 18:03:58.192569] [0x000000010d9eadc0] [info]    OS enumerate 187 fonts (+ 0 can't load = 187 fonts) in 18 ms

 

[2023-02-28 18:03:58.192585] [0x000000010d9eadc0] [debug]   Timer 'enumerate_fonts' spend 18ms

[2023-02-28 18:03:58.192600] [0x000000010d9eadc0] [trace]   '1;14;72;90;400;0;0;Helvetica;43'font descriptor string param of load_wxFont()

[2023-02-28 18:03:58.192624] [0x000000010d9eadc0] [trace]   '1;14;72;90;400;0;0;Helvetica;43' wx string descriptor

[2023-02-28 18:03:58.193215] [0x000000010d9eadc0] [trace]   loaded font is 'Helvetica'.

[2023-02-28 18:03:58.193240] [0x000000010d9eadc0] [trace]   '3;90;0;0;43;<plist version="1.0"><dict><key>NSCTFontTraitsAttribute</key><dict><key>NSCTFontProportionTrait</key><real>0.0</real><key>NSCTFontWeightTrait</key><real>0.0</real></dict><key>NSFontFamilyAttribute</key><string>Helvetica</string><key>NSFontSizeAttribute</key><real>13</real></dict></plist>'font descriptor string param of load_wxFont()

[2023-02-28 18:03:58.193269] [0x000000010d9eadc0] [trace]   '3;90;0;0;43;<plist version="1.0"><dict><key>NSCTFontTraitsAttribute</key><dict><key>NSCTFontProportionTrait</key><real>0.0</real><key>NSCTFontWeightTrait</key><real>0.0</real></dict><key>NSFontFamilyAttribute</key><string>Helvetica</string><key>NSFontSizeAttribute</key><real>13</real></dict></plist>' wx string descriptor

[Vojtěch Bubník]

> Is this on all 10.15 computers, or only on some ?

We don't know.

If you are able to compile and debug on Catalina, it should be quite simple to compile PrusaSlicer to reproduce the issue.

I cannot include a link to our PrusaSlicer gihtub (the list throws it away), but there is a wiki section on our PrusaSlicer github with build instructions for macOS and with a TL;DR section.

Vojtech

On Thu, Mar 2, 2023 at 9:57 AM Vojtěch Bubník <bub...@gmail.com> wrote:

> Is this on all 10.15 computers, or only on some ?

We don't know.

If you are able to compile and debug on Catalina, it should be quite simple to compile PrusaSlicer to reproduce the issue:
PrusaSlicer/How to build - Mac OS.md at master · prusa3d/PrusaSlicer (github.com)

Vojtech

--

Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/E6C82370-0CB6-4F89-83E6-A1030071D698%40advancedconcepts.ch.

[Stefan Csomor]

Hi

 

> Is this on all 10.15 computers, or only on some ?

 

We don't know.

 

Ok, got my 10.15 6 up and running 

alpha 4 crashes on this machine exactly the way he described, the moment I type a number into the height field after having erased the former content, 

Filip’s latest build 202303020702 works fine 😊 so I keep the fingers crossed …

 

And perhaps it would be good to increase wx within the 3.2 branch to the updated 3.2.2 ?

 

Best,

 

Stefan

 

[Vojtěch Bubník]

>  And perhaps it would be good to increase wx within the 3.2 branch to the updated 3.2.2 ?

We may do that, however we did a bit of customization to wxWidgets and we are now in the middle of release. We will upgrade after the release.

--

Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/GV0P278MB0243E7D1C28A00BD71D79CC3DDB29%40GV0P278MB0243.CHEP278.PROD.OUTLOOK.COM.

[Vojtěch Bubník]

> Filip’s latest build 202303020702 works fine

That's only because Filip gave up and rewrote the code to never ask again for the same font but with a different size.

We are projecting text onto 3D meshes. We were not sure whether the true type font system generates different font contours for different scaling. Indeed, large fonts are often printed with thinner features than small fonts. I remember from the times I used TeX/LaTeX that TeX fonts do that and I thought likely TTF fonts are as much powerful, but it is not the case, thus we may just produce contours for one fixed scaling and scale them ourselves and the crash is solved. 

Thanks again,

Vojtech

[Stefan Csomor]

Hi

 

>> Filip’s latest build 202303020702 works fine

 

>That's only because Filip gave up and rewrote the code to never ask again for the same font but with a different size.

 

ok, Filip, could you please send me the commit id, the question for me is still why suddenly a version 1 is serialized. These things may come back in disguise and haunt me again …

 

>We are projecting text onto 3D meshes. We were not sure whether the true type font system generates different font contours for different scaling. Indeed, >large fonts are often printed with thinner features than small fonts. I remember from the times I used TeX/LaTeX that TeX fonts do that and I thought likely >TTF fonts are as much powerful, but it is not the case, thus we may just produce contours for one fixed scaling and scale them ourselves and the crash is >solved. 

 

Yes, that still may be the case, so called hinting, but usually only for very small font sizes

 

Thanks,

 

Stefan

 

 

[Filip Sykala]

Hi Stefan,
crash still happens on actual master branch.

> ok, Filip, could you please send me the commit id, the question for me is still why suddenly a version 1 is serialized. These things may come back in disguise and haunt me again

The Commit which skip settings of SetPixelSize() is only on my not public branch yet. I am not sure whether commit Id(4c3ac0d9774e7108f43afbf16d10681f6a068fd3) will be permanent, when branch become public.

>  Yes, that still may be the case, so called hinting, but usually only for very small font sizes
From wiki Font hinting - Wikipedia I understand that hinting is connected only with rasterization process. So it is used only when shape(vector version) is transform to raster(pixel version). Am I right?

Thanks,

Filip

Dne čtvrtek 2. března 2023 v 14:37:50 UTC+1 uživatel Stefan Csomor napsal:

[Stefan Csomor]

Hi Filip

 

crash still happens on actual master branch.

Thanks, I have now a4 with all debugging symbols running with Memory Zombie detection on, so I can approach things slowly

Before the crash I get this in the log

[2023-03-03 09:21:39.589548] [0x000000013e89adc0] [error]   Can not process font('Helvetica'), file in path('/System/Library/Fonts/Helvetica.ttc#postscript-name=Helvetica') is not valid TTF.

2023-03-03 09:21:40.155270+0100 PrusaSlicer[30586:564742] *** -[CFString length]: message sent to deallocated instance 0x608000045ca0

So we have a zombie string that leads to this error here

static std::string get_file_path(const wxFont& font) {

    const wxNativeFontInfo *info = font.GetNativeFontInfo();

    if (info == nullptr) return {};

    CTFontDescriptorRef descriptor = info->GetCTFontDescriptor();

    CFURLRef            typeref    = (CFURLRef)

        CTFontDescriptorCopyAttribute(descriptor, kCTFontURLAttribute);

    if (typeref == NULL) return {};

    CFStringRef url = CFURLGetString(typeref);

    if (url == NULL) return {};

    wxString file_uri;

->    wxCFTypeRef(url).GetValue(file_uri);

    std::string file_path(wxURI::Unescape(file_uri).c_str());

    size_t start = std::string(file://).size();

    if (file_path.empty() || file_path.size() <= start)

        return {};

    // remove prefix file://

    file_path = file_path.substr(start, file_path.size() - start);

    return file_path;

}    

 

But already typeref is a zombie and descriptor cannot be printed to the debugger console, because this string attribute  is a zombie.
So the real damage comes from the invalid name within font descriptor, however this was possible.

I will try to find out.

> ok, Filip, could you please send me the commit id, the question for me is still why suddenly a version 1 is serialized. These things may come back in disguise and haunt me again
The Commit which skip settings of SetPixelSize() is only on my not public branch yet. I am not sure whether commit Id(4c3ac0d9774e7108f43afbf16d10681f6a068fd3) will be permanent, when branch become public.

Ok thanks

>  Yes, that still may be the case, so called hinting, but usually only for very small font sizes
From wiki Font hinting - Wikipedia I understand that hinting is connected only with rasterization process. So it is used only when shape(vector version) is transform to raster(pixel version). Am I right?

Yes, hinting is only for setting the best pixel representation at a small font size (https://learn.microsoft.com/en-us/typography/opentype/spec/ttch01) .
It’s not about having vector attributes like stroke width depending on point sizes (not being linearly scaled)

 

Best,

 

Stefan

[Stefan Csomor]

Hi Filip

Ok, I'm not right in front of the crash and the fontinfo string is now

"3;90;0;0;43;<plist version=\"1.0\"><dict><key>NSFontNameAttribute</key><string>Helvetica</string><key>NSFontSizeAttribute</key><real>13</real></dict></plist>"

Which is rather strange, because it does not have the kCTFontTraitsAttribute which usually is there, and which also was in the fontinfo strings from earlier moments which you posted.
So this one must have been constructed differently and not have gone through the normal font resolution by the OS. I'll try a guard.

Best,

Stefan

[Stefan Csomor]

Sorry

> Ok, I'm not right in front of the crash and the fontinfo string is now

Should have been "Ok, I'm now ... "

[Stefan Csomor]

Hi

Ok, it’s a ref counting problem within your get_file_path method

The rules for objects on macOS are related to the naming of methods, methods that contain a Copy or a Create in their name return an object that has to be released by the caller.

So the object you got from CTFontDescriptorCopyAttribute was missing a CFRelease,
and the code for transforming a CFStringRef into a wxString was overreleasing (a wxCFRef assumes ownership, so if it's attribute was retrieved using a ..Get.. method there's a CFRetain missing for this to work correctly)
but there is a simpler way to do this, I'd propose something along the following

static std::string get_file_path(const wxFont& font) {
const wxNativeFontInfo *info = font.GetNativeFontInfo();
if (info == nullptr) return {};
CTFontDescriptorRef descriptor = info->GetCTFontDescriptor();

CFURLRef typeref = (CFURLRef) CTFontDescriptorCopyAttribute(descriptor, kCTFontURLAttribute);
if (typeref == NULL) return {};
CFStringRef url = CFURLGetString(typeref);
if (url == NULL) return {};

wxString file_uri(wxCFStringRef::AsString(url));
CFRelease(typeref);

std::string file_path(wxURI::Unescape(file_uri).c_str());
size_t start = std::string("file://").size();
if (file_path.empty() || file_path.size() <= start)
return {};
// remove prefix file://
file_path = file_path.substr(start, file_path.size() - start);
return file_path;
}

Best,

Stefan

[Vojtěch Bubník]

So there was no issue on wxWidgets side, but on PrusaSlicer side (sic!). Thanks a lot  Stefan for solving our issue.

Maybe it would be worth to offer this hook of ours for accessing the font source file into platform specific wxWidgets API?

Thanks for considering,

Vojtech

--
Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/0D0401FC-A9DD-4E8A-B6D3-CE3704F315F6%40advancedconcepts.ch.

[Stefan Csomor]

Hi Vojtech

 

So there was no issue on wxWidgets side, but on PrusaSlicer side (sic!). Thanks a lot  Stefan for solving our issue.

 

You are very welcome

 

Maybe it would be worth to offer this hook of ours for accessing the font source file into platform specific wxWidgets API?

 

Why do you have to make sure it’s a real TTF in your PrusaSlicer ?

 

Best,

 

Stefan

[Vojtěch Bubník]

Stefan,

we are extracting outlines and we are projecting them to a 3d surface. Quite a hardcore stuff.

Vojtech

--

Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/4E2E5999-C66E-4666-A3B1-C10A5A8CAA48%40advancedconcepts.ch.