[cairo] Cairo glyph cache heap fragmentation

[Behdad Esfahbod]

On 14-09-17 11:32 PM, Bryce Harrington wrote:
> 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 mu

>  ch 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.

Not really.  Sounds to me like a system allocator issue.  Doesn't look like
there's a leak per se.

> 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.

-- 
behdad
http://behdad.org/