Valgrind traces show memory being lost in WebCore::FontCache::createFontPlatformData when calling FcFontMatch() and not freeing the returned FcPattern. There are several traces with different stack paths, but all end with this pattern: ==28564== 1,424 (512 direct, 912 indirect) bytes in 1 blocks are definitely lost in loss record 6,376 of 6,599 ==28564== at 0x4C28CCE: realloc (vg_replace_malloc.c:632) ==28564== by 0x78B5A57: FcPatternObjectInsertElt (fcpat.c:358) ==28564== by 0x78B68E7: FcPatternObjectAddWithBinding (fcpat.c:507) ==28564== by 0x78B34B7: FcFontRenderPrepare (fcmatch.c:416) ==28564== by 0x78B36CC: FcFontMatch (fcmatch.c:553) ==28564== by 0x627F969: WebCore::FontCache::createFontPlatformData(WebCore::FontDescription const&, WTF::AtomicString const&) (in /opt/jhbuild/gnome3/checkout/WebKit/WebKitBuild/Release/.libs/libwebkit2gtk-3.0.so.0.21.0)
This seems to be a problem in fontconfig and not in WebKit. This very same issue was reported several times in its bugzilla (being this the last one https://bugs.freedesktop.org/show_bug.cgi?id=34208) and it seems to be a false positive and not a leak.
(In reply to comment #1) > This seems to be a problem in fontconfig and not in WebKit. This very same issue was reported several times in its bugzilla (being this the last one https://bugs.freedesktop.org/show_bug.cgi?id=34208) and it seems to be a false positive and not a leak. Indeed it was also closed as NOTABUG here https://bugs.freedesktop.org/show_bug.cgi?id=8215. There is an ongoing patch adding valgrind suppressions which already contains this false positive. Let's close this then.