Bug 8215

Summary:	Leaks reported by valgrind
Product:	fontconfig	Reporter:	Kjartan Maraas <kmaraas>
Component:	library	Assignee:	Keith Packard <keithp>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	normal
Priority:	high
Version:	2.4
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	system font config file

Description Kjartan Maraas 2006-09-10 15:41:24 UTC

Valgrind reports the following leaks when I run GNOME programs:

==22256== 214 bytes in 9 blocks are definitely lost in loss record 93 of 186
==22256==    at 0x40053D0: malloc (vg_replace_malloc.c:149)
==22256==    by 0xDAED0D: FcStrCopy (fcstr.c:39)
==22256==    by 0xDB21D8: FcParsePatelt (fcxml.c:1907)
==22256==    by 0xDB468C: FcEndElement (fcxml.c:2157)
==22256==    by 0xD38215: doContent (xmlparse.c:2429)
==22256==    by 0xD38E8C: contentProcessor (xmlparse.c:2003)
==22256==    by 0xD39E8D: doProlog (xmlparse.c:3803)
==22256==    by 0xD3ADD4: prologProcessor (xmlparse.c:3551)
==22256==    by 0xD325CA: XML_ParseBuffer (xmlparse.c:1562)
==22256==    by 0xDB39C1: FcConfigParseAndLoad (fcxml.c:2469)
==22256==    by 0xDB3C9A: FcConfigParseAndLoad (fcxml.c:2355)
==22256==    by 0xDB3E03: FcParseInclude (fcxml.c:1609)
==22256==    by 0xDB48E1: FcEndElement (fcxml.c:2088)
==22256==    by 0xD38215: doContent (xmlparse.c:2429)
==22256==    by 0xD38E8C: contentProcessor (xmlparse.c:2003)
==22256==    by 0xD325CA: XML_ParseBuffer (xmlparse.c:1562)
==22256==    by 0xDB39C1: FcConfigParseAndLoad (fcxml.c:2469)
==22256==    by 0xDA4980: FcInitLoadConfig (fcinit.c:67)
==22256==    by 0xDA4DF7: FcInit (fcinit.c:82)
==22256==    by 0xD9B2EF: FcConfigSubstituteWithPat (fccfg.c:355)
==22256==    by 0xD9B360: FcConfigSubstitute (fccfg.c:1507)
==22256==    by 0xDCAF21: pango_cairo_fc_font_map_context_substitute
(pangocairo-fcfontmap.c:95)
==22256==    by 0x1F58B8: pango_fc_default_substitute (pangofc-fontmap.c:960)
==22256==    by 0x1F79E0: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1053)
==22256==    by 0x700C8F: pango_font_map_load_fontset (pango-fontmap.c:107)
==22256==    by 0x6FED11: itemize_state_process_run (pango-context.c:1045)
==22256==    by 0x6FF051: pango_itemize_with_base_dir (pango-context.c:1196)
==22256==    by 0x706F90: pango_layout_check_lines (pango-layout.c:3328)
==22256==    by 0x707B6B: pango_layout_get_extents_internal (pango-layout.c:2064)
==22256==    by 0x708B3C: pango_layout_get_pixel_extents (pango-layout.c:2257)

and

==22256== 1,332 (1,152 direct, 180 indirect) bytes in 9 blocks are definitely
lost in loss record 139 of 186
==22256==    at 0x40053D0: malloc (vg_replace_malloc.c:149)
==22256==    by 0xDAC425: FcPatternObjectInsertElt (fcpat.c:366)
==22256==    by 0xDAD117: FcPatternObjectAddWithBinding (fcpat.c:514)
==22256==    by 0xDAD29E: FcPatternAppend (fcpat.c:986)
==22256==    by 0xDB4090: FcParsePattern (fcxml.c:1994)
==22256==    by 0xDB469C: FcEndElement (fcxml.c:2154)
==22256==    by 0xD38215: doContent (xmlparse.c:2429)
==22256==    by 0xD38E8C: contentProcessor (xmlparse.c:2003)
==22256==    by 0xD39E8D: doProlog (xmlparse.c:3803)
==22256==    by 0xD3ADD4: prologProcessor (xmlparse.c:3551)
==22256==    by 0xD325CA: XML_ParseBuffer (xmlparse.c:1562)
==22256==    by 0xDB39C1: FcConfigParseAndLoad (fcxml.c:2469)
==22256==    by 0xDB3C9A: FcConfigParseAndLoad (fcxml.c:2355)
==22256==    by 0xDB3E03: FcParseInclude (fcxml.c:1609)
==22256==    by 0xDB48E1: FcEndElement (fcxml.c:2088)
==22256==    by 0xD38215: doContent (xmlparse.c:2429)
==22256==    by 0xD38E8C: contentProcessor (xmlparse.c:2003)
==22256==    by 0xD325CA: XML_ParseBuffer (xmlparse.c:1562)
==22256==    by 0xDB39C1: FcConfigParseAndLoad (fcxml.c:2469)
==22256==    by 0xDA4980: FcInitLoadConfig (fcinit.c:67)
==22256==    by 0xDA4DF7: FcInit (fcinit.c:82)
==22256==    by 0xD9B2EF: FcConfigSubstituteWithPat (fccfg.c:355)
==22256==    by 0xD9B360: FcConfigSubstitute (fccfg.c:1507)
==22256==    by 0xDCAF21: pango_cairo_fc_font_map_context_substitute
(pangocairo-fcfontmap.c:95)
==22256==    by 0x1F58B8: pango_fc_default_substitute (pangofc-fontmap.c:960)
==22256==    by 0x1F79E0: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1053)
==22256==    by 0x700C8F: pango_font_map_load_fontset (pango-fontmap.c:107)
==22256==    by 0x6FED11: itemize_state_process_run (pango-context.c:1045)
==22256==    by 0x6FF051: pango_itemize_with_base_dir (pango-context.c:1196)

and

==22256== 49,560 (15,360 direct, 34,200 indirect) bytes in 60 blocks are
definitely lost in loss record 177 of 186
==22256==    at 0x40054CB: realloc (vg_replace_malloc.c:306)
==22256==    by 0xDAC33E: FcPatternObjectInsertElt (fcpat.c:357)
==22256==    by 0xDAD117: FcPatternObjectAddWithBinding (fcpat.c:514)
==22256==    by 0xDAD3F6: FcPatternObjectAdd (fcpat.c:544)
==22256==    by 0xDA9163: FcFontRenderPrepare (fcmatch.c:454)
==22256==    by 0x1F7AF8: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1081)
==22256==    by 0x700C8F: pango_font_map_load_fontset (pango-fontmap.c:107)
==22256==    by 0x6FED11: itemize_state_process_run (pango-context.c:1045)
==22256==    by 0x6FF051: pango_itemize_with_base_dir (pango-context.c:1196)
==22256==    by 0x706F90: pango_layout_check_lines (pango-layout.c:3328)
==22256==    by 0x707B6B: pango_layout_get_extents_internal (pango-layout.c:2064)
==22256==    by 0x45A58B: gtk_label_size_request (gtklabel.c:2117)
==22256==    by 0x1B68C8: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566)
==22256==    by 0x1A86F8: g_type_class_meta_marshal (gclosure.c:567)
==22256==    by 0x1A9FEC: g_closure_invoke (gclosure.c:490)
==22256==    by 0x1BB319: signal_emit_unlocked_R (gsignal.c:2368)
==22256==    by 0x1BC37E: g_signal_emit_valist (gsignal.c:2197)
==22256==    by 0x1BDDBD: g_signal_emit_by_name (gsignal.c:2265)
==22256==    by 0x4D2455: do_size_request (gtksizegroup.c:583)
==22256==    by 0x4D26A6: _gtk_size_group_compute_requisition (gtksizegroup.c:779)
==22256==    by 0x5871DB: gtk_widget_size_request (gtkwidget.c:2866)
==22256==    by 0x57DAAF: gtk_vbox_size_request (gtkvbox.c:95)
==22256==    by 0x1B68C8: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566)
==22256==    by 0x1A86F8: g_type_class_meta_marshal (gclosure.c:567)
==22256==    by 0x1A9FEC: g_closure_invoke (gclosure.c:490)
==22256==    by 0x1BB319: signal_emit_unlocked_R (gsignal.c:2368)
==22256==    by 0x1BC37E: g_signal_emit_valist (gsignal.c:2197)
==22256==    by 0x1BDDBD: g_signal_emit_by_name (gsignal.c:2265)
==22256==    by 0x4D2455: do_size_request (gtksizegroup.c:583)
==22256==    by 0x4D26A6: _gtk_size_group_compute_requisition (gtksizegroup.c:779)

Comment 1 Keith Packard 2006-09-10 15:58:03 UTC

The first one looks like a fairly simple leak caused by some configuration
combination I haven't tested; I'll need a complete copy of all of the
configuration files included in this environment (including any ~/.fonts.conf).
Also, please try to reproduce this with fc-list or fc-match.

Comment 2 Keith Packard 2006-09-10 16:07:18 UTC

actually, neither of these are certainly leaks; fontconfig uses 'interesting'
data structures these days where objects are referred to by offset rather than
directly by pointers. I'm not sure how we can teach valgrind about this; it's
rather complicated. 

Given that the enclosing pattern objects aren't being marked as lost, I'm
betting the referenced pattern elements are still referenced, just not in a way
valgrind can see.

I'm going to mark this as 'notabug'. If you can somehow convince pango to
release all of the fontconfig patterns and still see leaks, then please reopen
it and I'll investigate further.

Comment 3 Kjartan Maraas 2006-09-10 16:09:04 UTC

Created attachment 6899 [details]
system font config file

This is a standard FC6 devel install and I have no ~/.fonts.conf

Comment 4 Kjartan Maraas 2006-09-10 16:11:07 UTC

I guess the right thing to do then would be to make the valgrind suppression
file handle this?

Comment 5 Keith Packard 2006-09-10 16:39:41 UTC

Yeah, I think we probably should do that for pattern elements and charset pieces
as well. btw -- are you using the new configuration setup? Or just leaving that
part alone?

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.