[Fontconfig] FontConfig memory question

[mathog]

On 13-Feb-2014 19:11, Akira TAGOH wrote:
> This one may be okay because fontconfig do the memory allocation to
> manage the non-built-in object types which isn't freed.

Inkscape uses fontconfig, pango, cairo, freetype, gtk, gtkmm, etc.

If these are placed just before the exit from main()

     FcInit();
     FcFini();

it blows up in FcFini() with

   inkscape: fccache.c:507: FcCacheFini: Assertion `fcCacheChains[i] == 
((void *)0)' failed.

which tells us that something, somewhere, is not releasing some memory 
fontconfig is managing.

Running inkscape in gdb and doing

(gdb) break FcNameParse
(gdb) break FcFontRenderPrepare

throws up this back trace at the first hit

#0  0x0108d630 in FcFontRenderPrepare () from 
/usr/lib/i386-linux-gnu/libfontconfig.so.1
#1  0x0108d94a in FcFontMatch () from 
/usr/lib/i386-linux-gnu/libfontconfig.so.1
#2  0x0100b182 in ?? () from 
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0
#3  0x0100b377 in ?? () from 
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0
#4  0x01047406 in pango_fontset_foreach () from 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0
#5  0x010093b6 in ?? () from 
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0
#6  0x0104682f in pango_font_map_load_font () from 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0
#7  0x01043707 in ?? () from /usr/lib/i386-linux-gnu/libpango-1.0.so.0
#8  0x01043fb0 in ?? () from /usr/lib/i386-linux-gnu/libpango-1.0.so.0
#9  0x01044d5f in pango_itemize_with_base_dir () from 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0
#10 0x0104cc86 in ?? () from /usr/lib/i386-linux-gnu/libpango-1.0.so.0
#11 0x0104ee56 in pango_layout_get_unknown_glyphs_count () from 
/usr/lib/i386-linux-gnu/libpango-1.0.so.0
#12 0x005eb924 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#13 0x005f0b13 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#14 0x012b16be in g_type_create_instance () from 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#15 0x01294508 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#16 0x01295cf9 in g_object_newv () from 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#17 0x00d16bee in Glib::Object::Object(Glib::ConstructParams const&) () 
from /usr/lib/i386-linux-gnu/libglibmm-2.4.so.1
#18 0x0030fc5d in Gtk::Object::Object(Glib::ConstructParams const&) () 
from /usr/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#19 0x0038da4d in Gtk::Widget::Widget(Glib::ConstructParams const&) () 
from /usr/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#20 0x002d9488 in Gtk::Entry::Entry(Glib::ConstructParams const&) () 
from /usr/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#21 0x0033ffeb in Gtk::SpinButton::SpinButton(double, unsigned int) () 
from /usr/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#22 0x085526fd in Inkscape::UI::Widget::SpinButton::SpinButton 
(this=0x9f8b314, climb_rate=0.02, digits=0, __in_chrg=<optimized out>,
     __vtt_parm=<optimized out>) at ./ui/widget/spinbutton.h:43
#23 0x08803ed8 in Inkscape::UI::Widget::SelectedStyle::SelectedStyle 
(this=0x9f8b0f8, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
     at ui/widget/selected-style.cpp:155
#24 0x08498d71 in SPDesktopWidget::init (dtw=0x9c050d8) at 
widgets/desktop-widget.cpp:615
#25 0x012b170b in g_type_create_instance () from 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#26 0x01294508 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#27 0x01296231 in g_object_newv () from 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#28 0x012967c8 in g_object_new () from 
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#29 0x0849d054 in SPDesktopWidget::createInstance (namedview=0x9181a30) 
at widgets/desktop-widget.cpp:1668
#30 0x0849d01d in sp_desktop_widget_new (namedview=0x9181a30) at 
widgets/desktop-widget.cpp:1661
#31 0x080f53fe in sp_file_new (templ=...) at file.cpp:155
#32 0x080f57b4 in sp_file_new_default () at file.cpp:224
#33 0x08087823 in sp_main_gui (argc=1, argv=0xbffff6e4) at main.cpp:1087
#34 0x08086f00 in main (argc=1, argv=0xbffff6e4) at main.cpp:806

That is, the Inkscape code starts 22 stack levels up from where some 
fontconfig memory is allocated.
There are far too many hits on this breakpoint to keep track of all of 
them, and I can't pull any information out of the lowest stack level 
since that OS provided library isn't compiled for it.

Now it may be that the leak corresponding to the FcFini() crash is 
elsewhere in Inkscape, which does call pango_font_description_new() and  
pango_font_description_free() directly.

Given this heap of code, and the problem that fontconfig hides whatever 
it is doing with memory, is there some efficient way to figure out 
_which_ piece of memory has not been released, and where it was 
initially allocated?  Some sort of trace option that can be set that 
will work  with the existing  fontconfig library perhaps?

I'm thinking it will probably come down to building a debug version of 
fontconfig, linking with that, and then tracking a whole lot of 
pointers.

Thanks,

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