981220 - Pixman fails to free TLS memory

Status: NEW

(Core :: Graphics, defect)

Description

[Andrew McCreight [:mccr8]]

I don't know if this is a big deal or not, and I also don't know whether this is the fault of the library, or if the browser is just failing to call some method to free the memory.  But anyways, I see this leak with LSAN in a few Mochitests:

Direct leak of 384 byte(s) in 1 object(s) allocated from:
    #0 0x446434 in calloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:90
    #1 0x7f047f57fabf in tls_fast_path_cache_alloc /somepath/gfx/cairo/libpixman/src/pixman-implementation.c:66
    #2 0x7f047f57fabf in tls_fast_path_cache_get /somepath/gfx/cairo/libpixman/src/pixman-implementation.c:66
    #3 0x7f047f57fabf in _pixman_implementation_lookup_composite /somepath/gfx/cairo/libpixman/src/pixman-implementation.c:91
    #4 0x7f047f464a54 in _cairo_pattern_acquire_surface_for_gradient /somepath/gfx/cairo/cairo/src/cairo-pattern.c:1524
    #5 0x7f047f464a54 in _cairo_pattern_acquire_surface /somepath/gfx/cairo/cairo/src/cairo-pattern.c:2417
    #6 0x7f047f4656ae in _cairo_pattern_acquire_surfaces /somepath/gfx/cairo/cairo/src/cairo-pattern.c:2496
    #7 0x7f047f3aee1e in _cairo_xlib_surface_acquire_pattern_surfaces /somepath/gfx/cairo/cairo/src/cairo-xlib-surface.c:2304
    #8 0x7f047f3aee1e in _cairo_xlib_surface_composite /somepath/gfx/cairo/cairo/src/cairo-xlib-surface.c:2471

Comment 1

[Jeff Muizelaar [:jrmuizel]]

This is being allocate as part of a pthread_key_create. It should be freed with the pthread destructor. Are those not being called for some reason?

Comment 2

[Andrew McCreight [:mccr8]]

> Are those not being called for some reason?
ASan runs are non-debug builds.  Maybe the cleanup is skipped for the main thread or something?  We leak exactly one of these objects on every Mochitest except dt, which doesn't leak any.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Main thread cleanup should be run from here:

https://sourceware.org/git/?p=glibc.git;a=blob;f=csu/libc-start.c;h=138418a1d15aff1cacc9e635050833c897c357fd;hb=HEAD#l298

Are we exiting ungracefully? Or maybe the leak checking is happening to early? before the pthread_key destructors can run.