Hold on to data used for FT_New_Memory_Face until after FT_Done_Face is called. #19
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
FreeType documentation for FT_New_Memory_face at https://freetype.org/freetype2/docs/reference/ft2-base_interface.html specifies "You must not deallocate the memory before calling FT_Done_Face", but it looks like we pass it a pointer to the contents of a vector that goes out of scope. This change just does a simple char* malloc and holds onto it until free_fontstack.
I came across this while debugging missing/corrupted glyphs showing up in a large set of SDFs. To my surprise, the missing glyphs showed up when I ran font-maker a second time with the same inputs, and then when I put some debugging code in to capture the set of glyphs, I found that the set of glyphs changed from one run to the next.
Looking at the code, I saw this, it looked suspicious, and when I changed it the set of glyphs started being reproducible between runs. I haven't done much else to verify the change (didn't actually observe memory corruption in the debugger or anything), but it seems pretty straightforward, at least if I'm reading the docs right.
@bdon