GNOME Bugzilla – Bug 573389
valgrind says pango/fontconfig is leaking memory
Last modified: 2009-02-27 13:36:06 UTC
I've been finding that pidgin will OOM on me every few days so I ran it with valgrind to see what's going on and it reported (if I'm understanding valgrind's output) memory leaks in pango/fontconfig. Here's the largest offender: ==23276== 605,992 (207,872 direct, 398,120 indirect) bytes in 601 blocks are definitely lost in loss record 393 of 398 ==23276== at 0x4025E4C: realloc (vg_replace_malloc.c:429) ==23276== by 0x4DBD971: FcPatternObjectInsertElt (fcpat.c:358) ==23276== by 0x4DBE3E7: FcPatternObjectAddWithBinding (fcpat.c:515) ==23276== by 0x4DBEA2B: FcPatternObjectAdd (fcpat.c:545) ==23276== by 0x4DBA98D: FcFontRenderPrepare (fcmatch.c:444) ==23276== by 0x4C91EBA: pango_fc_font_map_load_fontset (pangofc-fontmap.c:1098) ==23276== by 0x46FE539: pango_font_map_load_fontset (pango-fontmap.c:138) ==23276== by 0x46FC17B: itemize_state_process_run (pango-context.c:1280) ==23276== by 0x46FC65E: pango_itemize_with_base_dir (pango-context.c:1466) ==23276== by 0x4705288: pango_layout_check_lines (pango-layout.c:3824) ==23276== by 0x470679A: pango_layout_get_extents_internal (pango-layout.c:2443) ==23276== by 0x4C8E96E: pango_fc_font_create_metrics_for_context (pangofc-font.c:496) ==23276== by 0x4C06CF3: pango_cairo_fc_font_create_metrics_for_context (pangocairo-fcfont.c:74) ==23276== by 0x4C036E5: _pango_cairo_font_get_metrics (pangocairo-font.c:250) ==23276== by 0x46F5537: pango_font_get_metrics (fonts.c:1410) ==23276== by 0x470242C: pango_layout_get_empty_extents_at_index (pango-layout.c:4388) ==23276== by 0x47028D1: pango_layout_line_get_extents (pango-layout.c:4423) ==23276== by 0x47029B6: get_line_extents_layout_coords (pango-layout.c:2390) ==23276== by 0x47068C0: pango_layout_get_extents_internal (pango-layout.c:2501) ==23276== by 0x4434A65: gtk_text_layout_get_line_display (gtktextlayout.c:2437) ==23276== by 0x4438971: gtk_text_layout_real_wrap (gtktextlayout.c:1147) ==23276== by 0x4432DDE: gtk_text_layout_wrap (gtktextlayout.c:693) ==23276== by 0x4415A00: _gtk_text_btree_validate_line (gtktextbtree.c:5422) ==23276== by 0x44375C0: gtk_text_layout_validate_yrange (gtktextlayout.c:1062) ==23276== by 0x4444108: gtk_text_view_validate_onscreen (gtktextview.c:3408) ==23276== by 0x44456F4: gtk_text_view_flush_first_validate (gtktextview.c:3464) ==23276== by 0x444D7C8: gtk_text_view_size_allocate (gtktextview.c:3374) ==23276== by 0x80B0C94: gtk_imhtml_size_allocate (gtkimhtml.c:395) ==23276== by 0x4740A3B: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==23276== by 0x47323C8: g_type_class_meta_marshal (gclosure.c:878) ==23276== by 0x4733B77: g_closure_invoke (gclosure.c:767) ==23276== by 0x47498ED: signal_emit_unlocked_R (gsignal.c:3174) ==23276== by 0x474B7AB: g_signal_emit_valist (gsignal.c:2977) ==23276== by 0x474BC25: g_signal_emit (gsignal.c:3034) ==23276== by 0x44A8453: gtk_widget_size_allocate (gtkwidget.c:3878) ==23276== by 0x43E9ADA: gtk_scrolled_window_size_allocate (gtkscrolledwindow.c:1364) ==23276== by 0x4740A3B: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==23276== by 0x47323C8: g_type_class_meta_marshal (gclosure.c:878) ==23276== by 0x4733B77: g_closure_invoke (gclosure.c:767) ==23276== by 0x47498ED: signal_emit_unlocked_R (gsignal.c:3174) There are many of these in the log I will attach.
Created attachment 129650 [details] valgrind log of memory leaks
Since fontconfig does not use pointers to chain its elements together but offsets of one location to the next (since it has to work with mmaped files as well), valgrind cannot determine the reachability of the fontconfig blocks and hence produces false positive reports. Also simply opening and closing pidgin is not recreating the conditions under which the oom occurs, so you cannot infer from this report where the leak is. A more thorough test will probably indicate that pidgin loads a fresh spelling dictionary for every textview, and that is most likely the culprit consuming all available memory.
(In reply to comment #2) > Since fontconfig does not use pointers to chain its elements together but > offsets of one location to the next (since it has to work with mmaped files as > well), valgrind cannot determine the reachability of the fontconfig blocks and > hence produces false positive reports. That's a pity. > Also simply opening and closing pidgin is not recreating the conditions under > which the oom occurs, so you cannot infer from this report where the leak is. Well, of course, I didn't simply open and close pidgin to create this valgrind log. I did actually use it for a while. > A > more thorough test will probably indicate that pidgin loads a fresh spelling > dictionary for every textview, and that is most likely the culprit consuming > all available memory. I keep my conversation windows open all the time as my use is 95% irc (i.e. one conversation window per irc channel) so makes for pretty static textview usage I would think. I'm not a gtk programming expert though. I don't even play one on TV. :-)