GNOME Bugzilla – Bug 356449
Serious leak
Last modified: 2007-01-08 05:36:17 UTC
I found this after running evolution under valgrind with a11y enabled: ==10087== 18,416,159 (8,609,784 direct, 9,806,375 indirect) bytes in 239,161 blocks are definitely lost in loss record 257 of 264 ==10087== at 0x4004705: calloc (vg_replace_malloc.c:279) ==10087== by 0x508B36D: g_malloc0 (gmem.c:150) ==10087== by 0x470B635: ORBit_alloc_by_tc (allocators.c:373) ==10087== by 0x47069CC: ORBit_small_alloc (orbit-small.c:44) ==10087== by 0x58FE047: spi_init_any_rect (util.c:192) ==10087== by 0x53E0109: spi_atk_bridge_signal_listener (bridge.c:1214) ==10087== by 0x4FC4FDD: signal_emit_unlocked_R (gsignal.c:2404) ==10087== by 0x4FC6726: g_signal_emit_valist (gsignal.c:2197) ==10087== by 0x4FC94CD: g_signal_emit_by_name (gsignal.c:2265) ==10087== by 0x53BF99C: gail_widget_size_allocate_gtk (gailwidget.c:961) ==10087== by 0x4FC1828: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==10087== by 0x4FB4E7A: g_closure_invoke (gclosure.c:490) ==10087== by 0x4FC5202: signal_emit_unlocked_R (gsignal.c:2438) ==10087== by 0x4FC6726: g_signal_emit_valist (gsignal.c:2197) ==10087== by 0x4FC68E8: g_signal_emit (gsignal.c:2241) ==10087== by 0x4A270C9: gtk_widget_size_allocate (gtkwidget.c:3059) ==10087== by 0x45894AB: bonobo_widget_size_allocate (bonobo-widget.c:426) ==10087== by 0x4FC1828: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==10087== by 0x4FB3668: g_type_class_meta_marshal (gclosure.c:567) ==10087== by 0x4FB4F5C: g_closure_invoke (gclosure.c:490) ==10087== by 0x4FC5699: signal_emit_unlocked_R (gsignal.c:2368) ==10087== by 0x4FC6726: g_signal_emit_valist (gsignal.c:2197) ==10087== by 0x4FC68E8: g_signal_emit (gsignal.c:2241) ==10087== by 0x4A270C9: gtk_widget_size_allocate (gtkwidget.c:3059) ==10087== by 0x492D097: gtk_notebook_size_allocate (gtknotebook.c:1972) ==10087== by 0x4FC1828: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==10087== by 0x4FB3668: g_type_class_meta_marshal (gclosure.c:567) ==10087== by 0x4FB4F5C: g_closure_invoke (gclosure.c:490) ==10087== by 0x4FC5699: signal_emit_unlocked_R (gsignal.c:2368) ==10087== by 0x4FC6726: g_signal_emit_valist (gsignal.c:2197) Looks like something that was reported earlier, but where the fix caused crashes so it was backed out? My memory is dim...
Is the memory allocated in the spi_init_any_* calls ever freed? I can't find out where at least.
Kjartan: the memory should be freed in registry_flush_event_queue (registry.c, 722) and/or registry_queue_event (registry.c, 854). What version are you seeing this in? The fix was re-applied to HEAD for the 2.16 series.
I think I see the problem; the revised patch only plugs part of the leak (since it checks for "!any" before calling CORBA_free. Fixing this will require a bit more work, since if we always free when _release is true, some double free crashes will result.
bumping up priority since cause is more or less understood and big leaks are serious.
Should we put this on target for 2.18.0?
Yes, let's. We'll give it our best shot.
(In reply to comment #3) > I think I see the problem; the revised patch only plugs part of the leak (since > it checks for "!any" before calling CORBA_free. > Fixing this will require a bit more work, since if we always free when _release > is true, some double free crashes will result. > Can you put the link for the patch Bill? Thanks!
Is this in any way related to the commit by Li earlier today? It was for bug 352444 IIRC
Created attachment 78374 [details] valgrind output After compiling ATK with Li patch I don't percepted any big memory leak in Evolution related with the valgrind output that you showed. I used it for about one hour, receiving, sending and reading some messages. The bigget leak I get related with spi_init_any_* was about 500Kb. Maybe your report cover a code path that I don't went into or Li's patch corrected that. Does you still have this memory leak under valgrind, Kjartan? Although this I find another leak (I think that this one is Evolution related), but I'm not certain of this, so I decide to attach my valgrind output and the leak: ==7595== 11,841,444 bytes in 182 blocks are still reachable in loss record 278 of 278 ==7595== at 0x401C564: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==7595== by 0x54C6EE9: g_try_malloc (gmem.c:196) ==7595== by 0x447F9EB: gdk_pixbuf_new (gdk-pixbuf.c:272) ==7595== by 0x4BBD3BC: bonobo_ui_util_xml_to_pixbuf (bonobo-ui-util.c:208) ==7595== by 0x4BBD9EC: bonobo_ui_util_xml_set_image (bonobo-ui-util.c:412) ==7595== by 0x4BB34D3: impl_bonobo_ui_sync_menu_state (bonobo-ui-sync-menu.c:369) ==7595== by 0x4BB0FAD: bonobo_ui_sync_state (bonobo-ui-sync.c:159) ==7595== by 0x4BABB44: bonobo_ui_engine_sync (bonobo-ui-engine.c:2265) ==7595== by 0x4BABC4C: bonobo_ui_engine_sync (bonobo-ui-engine.c:2339) ==7595== by 0x4BABFB7: do_sync (bonobo-ui-engine.c:2404) ==7595== by 0x4BAC16D: seek_dirty (bonobo-ui-engine.c:2439) ==7595== by 0x4BAC16D: seek_dirty (bonobo-ui-engine.c:2439)
*** This bug has been marked as a duplicate of 352444 ***