987918 - Enable CLEANUP_MEMORY in ASAN builds

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Andrew McCreight [:mccr8]]

Attachment: leak stack

In mochitest-5, LeakSanitizer detects a number of leaks in gfxFcFontSet::gfxFcFontSet.  The full stack trace of the allocation is attached.  The line number isn't very useful, as it points to a call to gfxFcFontSet::SortPreferredFonts.  I tried making it MOZ_NEVER_INLINE and it didn't produce a better stack.

Just as a note, there are a bunch more LSAN leak stacks that have libfontconfig.so in them.  I just need to get a debug version so the stack walking can produce something more useful.  I have no idea why this stack in particular looks useful.

Comment 1

[Andrew McCreight [:mccr8]]

This is a leak that is occuring when running the Mochitests in layout/style/test/.  It shows about 13kb of leaks.

Comment 2

[Karl Tomlinson (:karlt)]

> Direct leak of 13824 byte(s) in 576 object(s) allocated from:

576 objects of size 24, perhaps.

> #1 0x7f854b23546d (/usr/lib/libfontconfig.so.1+0x1b46d)

If you are able to use addr2line to identify this function, it may provide a clue.

Comment 3

[Andrew McCreight [:mccr8]]

I installed debug symbols for this library, so I should be able to retest at some point, maybe not until next week.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh -- and I'm not sure if fontconfig uses the glib slab allocator, but when debugging memory stuff on Linux it's generally good to use G_SLICE=always-malloc in the environment.

I tried to repro this using trace-malloc, but I don't see any leaks looking like this in the shutdown-leaks log.  (There are some one-time allocations with similar stacks, but nothing with that number or size of allocations.)

Comment 5

[Andrew McCreight [:mccr8]]

Attachment: font stacks, with more symbols

Ok, I finally got around to putting this together. Here are the font-related direct leaks I see when running the layout directory.

The mystery symbol turned out to be
  #1 0x7f7aeebe66dd in IA__FcPatternCreate /home/johns/AUR/fontconfig/src/fontconfig-2.11.1/src/fcpat.c:33

I don't know if that is useful or not.

Comment 6

[Karl Tomlinson (:karlt)]

I'm not finding a place where I'd expect FcPatternCreate to be called from gfxFcFontSet() or SortPreferredFonts(), at least without some significant call chain that I would expect to show up in the stack traces.

> Direct leak of 297472 byte(s) in 580 object(s) allocated from:
>     #0 0x4687c3 in __interceptor_realloc (/home/amccreight/mc/obj-x86_64-unknown-linux-gnu/dist/bin/firefox+0x4687c3)
>     #1 0x7f7aeebe6e59 in FcPatternObjectInsertElt /home/johns/AUR/fontconfig/src/fontconfig-2.11.1/src/fcpat.c:436

Do you know why the stack trace ends here?

Do you know whether this build calls FcFini() is called before the app exits?
That depends on whether CLEANUP_MEMORY is set at
http://hg.mozilla.org/mozilla-central/annotate/b79c2995d25e/toolkit/xre/nsAppRunner.cpp#l215

I wonder whether some out of date fontconfig caches on this system may be causing fontconfig to generate FcPatterns in memory instead of from the mmapped caches.
I would have expected FcFini() to clean that up, but perhaps not.

Comment 7

[Andrew McCreight [:mccr8]]

> Do you know why the stack trace ends here?
The system library is probably not compiled with frame pointers.  For what it is worth, similar font stacks to that one, very short, show up in every Mochitest run.  There's some option I can set that may let me get a deeper stack.

> Do you know whether this build calls FcFini() is called before the app exits?
I don't know, I can look into that.  This is actually a non-debug build, so that would explain why the cleanup code isn't being called.

Comment 8

[Andrew McCreight [:mccr8]]

Ah, fantastic!  It looks like enabling CLEANUP_MEMORY gets rid of all of the font leaks I've been seeing.  I guess it makes sense to enable that when MOZ_ASAN is set.