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)
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.
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.
Created attachment 6899 [details] system font config file This is a standard FC6 devel install and I have no ~/.fonts.conf
I guess the right thing to do then would be to make the valgrind suppression file handle this?
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.