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