[cairo] No proper way to free cairo_font_face_t

[Fred Bca]

I have had the same issue with the MRU cache back in 2016 and proposed
a simple patch to avoid this issue at build time here:
https://lists.cairographics.org/archives/cairo/2016-April/027349.html
It avoids that cairo keeps the fonts in the mru cache when they have
been fully released, so you can release the objects on your side
without having to worry about it.

On Thu, Jan 6, 2022 at 3:18 PM Vladimir Sadovnikov <sadko4u at gmail.com> wrote:
>
> Hello!
>
> I'm writing here since I have a problem which is currently not resolvable for me.
>
> Consider we have a host GUI application which can load plugins which also can
> provide their own GUIs. This is not rare example since all Digital Audio
> Workstations (DAWs) work in such manner.
>
> Since each plugin is a shared object file, it can be loaded (when the plugin
> becomes activated) and unloaded by the host (when the plugin was removed).
>
> The main problem is when we try to load and use custom font in the plugin and
> uses the following scenario:
>
> 1. when starting UI, it calls FT_InitFreeType to create the FreeType library object.
>
> 2. it allocates custom fonts by calling:
>
>    a. malloc() to allocate the space for font file data.
>
>    b. FT_New_Memory_Face to create font face using the previously allocated font
> file data.
>
> 3. when drawing the text, it performs:
>
>    a. cairo_ft_font_face_create_for_ft_face
>
>    b. calls cairo_font_face_set_user_data to register user data associated with
> the font which:
>
>       - is additionally malloc()'ed
>
>       - holds the pointer to font file data which was malloc()'ed in 2.a
>
>       - holds the pointer to FT_Face font handle object.
>
>    c. selects the font by calling cairo_set_font_face
>
>    d. performs the drawing of the text
>
> 4. Now, the plugin becomes deallocated. There are couple of problems:
>
>    a. Plugin should dispose the FT_New_Memory_Face object created in 2.b and
> free() the memory allocated in 2.a and 3.b. But because it is cached as a
> cairo_font_face_t object, it can not do it until cairo_font_face_t will be
> removed from cairo font cache.
>
>    b. If we set up a destruction routine in cairo_font_face_set_user_data, then
> we can not perform dlclose() on the plugin's shared object handle because after
> unloading the shared object, the pointer to the cairo_destroy_func_t routine
> becomes invalid.
>
>    c. Plugin should release the FreeType library object by calling
> FT_Done_FreeType. The documentation says about FT_Done_FreeType: 'Destroy a
> given FreeType library object and all of its children, including resources,
> drivers, faces, sizes, etc.' If the font face becomes destroyed, the cached
> cairo_font_face_t object becomes invalid since it points to the disposed data.
>
>    d. If we avoid freeing some memory resources, the memory will leak and once
> the host will crash by out-of-memory cause.
>
>
> Currently I don't have any ideas of solving problems related to 4. Having
> possibility to evict the cairo_font_face_t object from cairo cache would be a
> good option but there is no way to do this at this moment.
>
> So I would like to see any comments or recommendations related to my case.
>
>
> Best,
>
> Vladimir
>
>
>