libass: Memory leak in ass_font_provider_add_font
We are working on adding libass support to MPC-HC.
Visual Studio reported some memory leaks and after debugging I pinpointed it to ass_font_provider_add_font function where the data from implicit_meta is not freed in the success case.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 28 (10 by maintainers)
So, because I’m new to the programing and coding world, I am still unfamiliar with all the abbreviated commands and word syntax. I did get a good laugh though reading along. If I didn’t know better, I would have thought I was in an OFs sub-Reddit with all the mentions of leaked ass, freed ass, and implicit family members. So, thanks for that. 👍
As long as the font has any family names (which should always be the case), the leaking code path doesn’t run when using fontconfig, memory fonts, or sufficiently-new windows. It’s exclusive to macOS and older win32.
Leak shows up when closing the player. Libass is fully deinitialised. It leaks data for each non-embedded system font that is loaded. No DirectWrite. Git head for libass and also up-to-date other libs.
Here is example of leak details with three fonts loaded: https://pastebin.com/H5XuYKtV
Adding this before the
return truefixes the leak. Would of course need a pointer check as well before freeing.