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@xxxxxxxxxxx
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
