[cairo] Cairo glyph cache heap fragmentation

[Bryce Harrington]

On Mon, Sep 15, 2014 at 02:30:07PM +0000, Kaiser Bernhard wrote:
> Hi,
> We use revision 1.10.0.
> We use cairo in order to draw windows in a realtime operating system. During operation windows including text are opened and closed. Looking at the heap I can see, that the largest free block decreases until the heap manager requests memory from the memory manager. After a time the memory in the memory manager is 0 and with the next request of a big memory block (opening a new window, allocating the memory for the surface) we are running out of memory. The total available memory does nearly not decrease in this process, we can get memory in small blocks, but there is no big block available. We tried to find out what happens. We logged all heap operations and found out, that cairo allocates memory to add glyphs to the glyph cache. The glyph cache belongs to the font, not to the window, so if the window is closed (and the memory is freed), this small piece of memory stays allocated 'in the middle of the heap'. We reduced the define MAX_GLYPH_PAGES_CACHED from 255 to 4, and it took much longer to run out of memory.
> Can we disable the glyph cache or are there other solutions (update to 1.12.xx?)? Is there a possibility to use static allocated memory for glyph cache?
> 

Behdad would be a better person to answer this than me, so hopefully he
can chime in.

By chance is your application multithreaded?

Certainly it would be helpful to us if you could at least run a test
against 1.12.14 (or the 1.12.16 snapshot) so we'd know if the issue is
still in the current codebase; if it isn't there might be a patch you
could backport if you want to stay on 1.10.0.

Otherwise, my next question would be if there's a bug in
cairo-scaled-font.c that is causing a destructor to get skipped under
some circumstance.  cairo_scaled_font_destroy() appears to be an entry
point, so you could put in printf's there to make sure it's actually
getting called.  Put a printf in the constructor as well, and see if the
construction/destruction calls are balanced.  Alternatively, you could
run it with a memory leak checking tool like smatch, which should
provide some beter insights.

Bryce