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)

Commits related to this issue

Most upvoted comments

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 true fixes the leak. Would of course need a pointer check as well before freeing.

free_font_info(&implicit_meta);
free(implicit_meta.postscript_name);