New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Seg Fault with SKTypeface.MatchTypeface with Ubuntu #1148
Comments
I think this is because of the way the stream are working in skia vs .NET. In skia, the stream is "forked" by creating a new stream object that points to the same managed stream. This resulted in multiple streams modifying the managed stream location.
Is there a stack trace at all? |
I had a look at the source for the font manager for linux. It appears they literally just call https://github.com/mono/skia/blob/v1.68.1.1/src/ports/SkFontMgr_fontconfig.cpp#L911 return this->matchFamilyStyle(get_string(fcTypeface->fPattern, FC_FAMILY), style); I bet the font name is null or empty. Could you have a look? Not sure what we need to do there... I'll have a look around if this is the case. |
Hi, is there any way around this issue? |
We just decided on our Linux builds that the user just has to install onto the system whatever fonts they want to use. For instance, in our docker builds it just goes in as part of the setup. |
Description
When loading a font file from a file/stream in Ubuntu 18.04, it is possible to cause a seg fault in the process and instantly kill it. This is done by calling SKFontManager.MatchTypeface and providing it the loaded SKTypeface from the stream and an SKFontStyle. This code does not fail in Windows (and possibly iOS is okay too).
This was reproduced in a pair of VMs, one running Ubuntu 18.04.3 Server and the other via VS Code in 18.04.3 Desktop. I crashed a live server application running in an Ubuntu docker container by exploiting this. The repro below uses the latest 1.68.1.1 SkiaSharp, but the server application is running 1.68.0.
My theory is that this is an underlying problem with the Skia library. Their implementation is getting a wire crossed somewhere when given the stream loaded typeface and exploding in the unmanaged code. I'm not sure if there's anything that can necessarily be done on the SkiaSharp side if this is the case.
Code
This can be reproduced with a csproj and a cs file, and by using the easily obtained Roboto TTF font files downloaded from Google. This code runs x64 in .NET Core 3.1. Place the downloaded TTF files in the same folder as the csproj and Program.cs file.
CSProj contents:
Program.cs
Expected Behavior
It is expected that the program is run to completion, but when it reaches "Match 9", the call to MatchTypeface will cause a seg fault and instantly kill the program.
Actual Behavior
Here's the console output:
Basic Information
The text was updated successfully, but these errors were encountered: