[Fontconfig] FontConfig memory question

[mathog]

It could be that most of these leaks are not in fontconfig but in pango. 
  The valgrind entries mostly get to fontconfig with a call passing 
through pango_font_map_load_fontset().  If pango induces fontconfig to 
allocate memory, but it never tells it to release it, then that would 
explain valgrind entries like this:

==2513== 2 bytes in 1 blocks are indirectly lost in loss record 165 of 
47,988
==2513==    at 0x402BE68: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2513==    by 0x58A0C30: strdup (strdup.c:43)
==2513==    by 0x4FB1F39: FcValueSave (fcpat.c:95)
==2513==    by 0x4FB2E80: FcPatternObjectAddWithBinding (fcpat.c:608)
==2513==    by 0x4FB300E: FcPatternObjectAdd (fcpat.c:658)
==2513==    by 0x4FB3386: FcPatternObjectAddString (fcpat.c:777)
==2513==    by 0x4F29964: ??? (in 
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0.3000.0)
==2513==    by 0x4F65D26: pango_font_map_load_fontset (in 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2513==    by 0x4F62F58: ??? (in 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2513==    by 0x4F63D5E: pango_itemize_with_base_dir (in 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2513==    by 0x4F6BC85: ??? (in 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2513==    by 0x4F6CE43: ??? (in 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2513==    by 0x4F6D377: pango_layout_get_pixel_extents (in 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0.3000.0)
==2513==    by 0x44E455C: ??? (in 
/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2513==    by 0x44DC3B3: gtk_cell_renderer_get_size (in 
/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)

I was wrong about text_reassemble.c not having any leaked memory through 
fontconfig 2.11.  It does leak a little, but in a fairly mysterious way, 
and not from the section of code that was listed in the first post in 
this thread.  Here is one of the valgrind records:

==2513== 160 bytes in 1 blocks are still reachable in loss record 40,358 
of 47,988
==2513==    at 0x402BE68: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2513==    by 0x4FB623E: _FcStrSetAppend (fcstr.c:1201)
==2513==    by 0x4FB6AB4: FcStrSetAddFilename (fcstr.c:1260)
==2513==    by 0x4FA1A18: FcConfigAddCache (fccfg.c:358)
==2513==    by 0x4FA1AB2: FcConfigAddDirList (fccfg.c:382)
==2513==    by 0x4FA1D45: FcConfigBuildFonts (fccfg.c:412)
==2513==    by 0x4FABE8D: FcInitLoadOwnConfigAndFonts (fcinit.c:140)
==2513==    by 0x8385EDD: trinfo_init (text_reassemble.c:1502)
==2513==    by 0x83A53EA: 
Inkscape::Extension::Internal::Emf::open(Inkscape::Extension::Input*, 
char const*) (emf-inout.cpp:3426)
==2513==    by 0x8320A09: Inkscape::Extension::Input::open(char const*) 
(input.cpp:153)
==2513==    by 0x831E599: 
Inkscape::Extension::open(Inkscape::Extension::Extension*, char const*) 
(system.cpp:117)
==2513==    by 0x80F583C: sp_file_open(Glib::ustring const&, 
Inkscape::Extension::Extension*, bool, bool) (file.cpp:274)
==2513==    by 0x808778C: sp_main_gui(int, char const**) (main.cpp:1087)
==2513==    by 0x8086EAF: main (main.cpp:812)

The mystery is that trinfo_init does not call 
FcInitLoadOwnConfigAndFonts directly.  It calls ftinfo_init() which in 
turn calls FcInit(), and presumably somewhere down from there 
FcInitLoadOwnConfigAndFonts() is called.  Not sure why valgrind does not 
show these intervening functions.


Regards,

David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech