GNOME Bugzilla – Bug 331924
Various leaks reported by valgrind
Last modified: 2006-07-14 18:32:48 UTC
Found when running a gnome session under valgrind: From the registry daemon: ==23425== 6,622 bytes in 3,231 blocks are definitely lost in loss record 72 of 81 ==23425== at 0x4004F52: malloc (vg_replace_malloc.c:149) ==23425== by 0x46631F5: g_malloc (gmem.c:131) ==23425== by 0x414A18F: ORBit_alloc_string (allocators.c:228) ==23425== by 0x4149E58: CORBA_string_dup (corba-string.c:22) ==23425== by 0x804DBC5: spi_dec_mouse_check (deviceeventcontroller.c:517) ==23425== by 0x804F0B7: spi_dec_poll_mouse_moved (deviceeventcontroller.c:578) ==23425== by 0x804F150: spi_dec_poll_mouse_idle (deviceeventcontroller.c:593) ==23425== by 0x465C2E5: g_timeout_dispatch (gmain.c:3292) ==23425== by 0x465BBCC: g_main_context_dispatch (gmain.c:1916) ==23425== by 0x465EE4E: g_main_context_iterate (gmain.c:2547) ==23425== by 0x465F1F8: g_main_loop_run (gmain.c:2751) ==23425== by 0x40D1AD2: bonobo_main (bonobo-main.c:311) ==23425== by 0x804F320: main (registry-main.c:81) ==23425== 587,643 (125,692 direct, 461,951 indirect) bytes in 3,438 blocks are definitely lost in loss record 80 of 81 ==23425== at 0x40044E5: calloc (vg_replace_malloc.c:260) ==23425== by 0x466315D: g_malloc0 (gmem.c:150) ==23425== by 0x4149EB5: ORBit_alloc_by_tc (allocators.c:373) ==23425== by 0x414529C: ORBit_small_alloc (orbit-small.c:44) ==23425== by 0x403C217: spi_init_any_nil (util.c:121) ==23425== by 0x804DC02: spi_dec_mouse_check (deviceeventcontroller.c:517) ==23425== by 0x804F0B7: spi_dec_poll_mouse_moved (deviceeventcontroller.c:578) ==23425== by 0x804F150: spi_dec_poll_mouse_idle (deviceeventcontroller.c:593) ==23425== by 0x465C2E5: g_timeout_dispatch (gmain.c:3292) ==23425== by 0x465BBCC: g_main_context_dispatch (gmain.c:1916) ==23425== by 0x465EE4E: g_main_context_iterate (gmain.c:2547) ==23425== by 0x465F1F8: g_main_loop_run (gmain.c:2751) ==23425== by 0x40D1AD2: bonobo_main (bonobo-main.c:311) ==23425== by 0x804F320: main (registry-main.c:81) From gnome-panel: ==23495== 4,151 bytes in 169 blocks are definitely lost in loss record 191 of 212 ==23495== at 0x4004F52: malloc (vg_replace_malloc.c:149) ==23495== by 0x49431F5: g_malloc (gmem.c:131) ==23495== by 0x489218F: ORBit_alloc_string (allocators.c:228) ==23495== by 0x4891E58: CORBA_string_dup (corba-string.c:22) ==23495== by 0x40C17DB: spi_atk_bridge_init_base (bridge.c:1176) ==23495== by 0x40C1842: spi_atk_bridge_init_string (bridge.c:1205) ==23495== by 0x40C2888: spi_atk_bridge_property_event_listener (bridge.c:748) ==23495== by 0x48D866C: signal_emit_unlocked_R (gsignal.c:2404) ==23495== by 0x48D9D82: g_signal_emit_valist (gsignal.c:2197) ==23495== by 0x48DA028: g_signal_emit (gsignal.c:2241) ==23495== by 0x472091D: atk_object_notify (atkobject.c:1323) ==23495== by 0x48D4E02: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531) ==23495== by 0x48C5738: g_type_class_meta_marshal (gclosure.c:567) ==23495== by 0x48C6EFC: g_closure_invoke (gclosure.c:490) ==23495== by 0x48D8D99: signal_emit_unlocked_R (gsignal.c:2368) ==23495== by 0x48D9D82: g_signal_emit_valist (gsignal.c:2197) ==23495== by 0x48DA028: g_signal_emit (gsignal.c:2241) ==23495== by 0x48CB5A0: g_object_dispatch_properties_changed (gobject.c:561) ==23495== by 0x48C7CDE: g_object_notify_dispatcher (gobject.c:242) ==23495== by 0x48CC5E1: g_object_notify (gobjectnotifyqueue.c:123) ==23495== by 0x471F2DA: atk_object_set_name (atkobject.c:842) ==23495== by 0x809CD59: panel_a11y_set_atk_name_desc (panel-a11y.c:52) ==23495== by 0x8093AA5: panel_toplevel_update_description (panel-toplevel.c:1577) ==23495== by 0x8099CD6: panel_toplevel_size_request (panel-toplevel.c:2279) ==23495== by 0x48D4D42: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==23495== by 0x48C5738: g_type_class_meta_marshal (gclosure.c:567) ==23495== by 0x48C6EFC: g_closure_invoke (gclosure.c:490) ==23495== by 0x48D8D99: signal_emit_unlocked_R (gsignal.c:2368) ==23495== 7,009 (4,268 direct, 2,741 indirect) bytes in 119 blocks are definitely lost in loss record 192 of 212 ==23495== at 0x40044E5: calloc (vg_replace_malloc.c:260) ==23495== by 0x494315D: g_malloc0 (gmem.c:150) ==23495== by 0x4891EB5: ORBit_alloc_by_tc (allocators.c:373) ==23495== by 0x488D29C: ORBit_small_alloc (orbit-small.c:44) ==23495== by 0x4DC8117: spi_init_any_string (util.c:163) ==23495== by 0x40C1863: spi_atk_bridge_init_string (bridge.c:1206) ==23495== by 0x40C2888: spi_atk_bridge_property_event_listener (bridge.c:748) ==23495== by 0x48D866C: signal_emit_unlocked_R (gsignal.c:2404) ==23495== by 0x48D9D82: g_signal_emit_valist (gsignal.c:2197) ==23495== by 0x48DA028: g_signal_emit (gsignal.c:2241) ==23495== by 0x472091D: atk_object_notify (atkobject.c:1323) ==23495== by 0x48D4E02: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531) ==23495== by 0x48C5738: g_type_class_meta_marshal (gclosure.c:567) ==23495== by 0x48C6EFC: g_closure_invoke (gclosure.c:490) ==23495== by 0x48D8D99: signal_emit_unlocked_R (gsignal.c:2368) ==23495== by 0x48D9D82: g_signal_emit_valist (gsignal.c:2197) ==23495== by 0x48DA028: g_signal_emit (gsignal.c:2241) ==23495== by 0x48CB5A0: g_object_dispatch_properties_changed (gobject.c:561) ==23495== by 0x48C7CDE: g_object_notify_dispatcher (gobject.c:242) ==23495== by 0x48CC5E1: g_object_notify (gobjectnotifyqueue.c:123) ==23495== by 0x471F2DA: atk_object_set_name (atkobject.c:842) ==23495== by 0x809CD59: panel_a11y_set_atk_name_desc (panel-a11y.c:52) ==23495== by 0x8093AA5: panel_toplevel_update_description (panel-toplevel.c:1577) ==23495== by 0x8099CD6: panel_toplevel_size_request (panel-toplevel.c:2279) ==23495== by 0x48D4D42: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==23495== by 0x48C5738: g_type_class_meta_marshal (gclosure.c:567) ==23495== by 0x48C6EFC: g_closure_invoke (gclosure.c:490) ==23495== by 0x48D8D99: signal_emit_unlocked_R (gsignal.c:2368) ==23530== 12,862 bytes in 645 blocks are definitely lost in loss record 206 of 218 ==23530== at 0x4004F52: malloc (vg_replace_malloc.c:149) ==23530== by 0x49431F5: g_malloc (gmem.c:131) ==23530== by 0x489218F: ORBit_alloc_string (allocators.c:228) ==23530== by 0x4891E58: CORBA_string_dup (corba-string.c:22) ==23530== by 0x40C17DB: spi_atk_bridge_init_base (bridge.c:1176) ==23530== by 0x40C1842: spi_atk_bridge_init_string (bridge.c:1205) ==23530== by 0x40C2888: spi_atk_bridge_property_event_listener (bridge.c:748) ==23530== by 0x48D866C: signal_emit_unlocked_R (gsignal.c:2404) ==23530== by 0x48D9D82: g_signal_emit_valist (gsignal.c:2197) ==23530== by 0x48DA028: g_signal_emit (gsignal.c:2241) ==23530== by 0x472091D: atk_object_notify (atkobject.c:1323) ==23530== by 0x48D4E02: g_cclosure_marshal_VOID__PARAM (gmarshal.c:531) ==23530== by 0x48C5738: g_type_class_meta_marshal (gclosure.c:567) ==23530== by 0x48C6EFC: g_closure_invoke (gclosure.c:490) ==23530== by 0x48D8D99: signal_emit_unlocked_R (gsignal.c:2368) ==23530== by 0x48D9D82: g_signal_emit_valist (gsignal.c:2197) ==23530== by 0x48DA028: g_signal_emit (gsignal.c:2241) ==23530== by 0x48CB5A0: g_object_dispatch_properties_changed (gobject.c:561) ==23530== by 0x48C7CDE: g_object_notify_dispatcher (gobject.c:242) ==23530== by 0x48CC5E1: g_object_notify (gobjectnotifyqueue.c:123) ==23530== by 0x471F2DA: atk_object_set_name (atkobject.c:842) ==23530== by 0x809CD59: panel_a11y_set_atk_name_desc (panel-a11y.c:52) ==23530== by 0x8093AA5: panel_toplevel_update_description (panel-toplevel.c:1577) ==23530== by 0x8099CD6: panel_toplevel_size_request (panel-toplevel.c:2279) ==23530== by 0x48D4D42: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==23530== by 0x48C5738: g_type_class_meta_marshal (gclosure.c:567) ==23530== by 0x48C6EFC: g_closure_invoke (gclosure.c:490) ==23530== by 0x48D8D99: signal_emit_unlocked_R (gsignal.c:2368) from nautilus: ==23441== 6,823 bytes in 529 blocks are definitely lost in loss record 177 of 192 ==23441== at 0x4004F52: malloc (vg_replace_malloc.c:149) ==23441== by 0x4A651F5: g_malloc (gmem.c:131) ==23441== by 0x49CA18F: ORBit_alloc_string (allocators.c:228) ==23441== by 0x49C9E58: CORBA_string_dup (corba-string.c:22) ==23441== by 0x401C7DB: spi_atk_bridge_init_base (bridge.c:1176) ==23441== by 0x401D082: spi_atk_bridge_init_object (bridge.c:1195) ==23441== by 0x401D43C: spi_atk_bridge_signal_listener (bridge.c:1036) ==23441== by 0x4A1066C: signal_emit_unlocked_R (gsignal.c:2404) ==23441== by 0x4A11D82: g_signal_emit_valist (gsignal.c:2197) ==23441== by 0x4A13C5D: g_signal_emit_by_name (gsignal.c:2265) ==23441== by 0x8105E6A: nautilus_icon_container_accessible_icon_added_cb (nautilus-icon-container.c:7413) ==23441== by 0x4A0C7A2: g_cclosure_marshal_VOID__POINTER (gmarshal.c:601) ==23441== by 0x49FEEFC: g_closure_invoke (gclosure.c:490) ==23441== by 0x4A1090A: signal_emit_unlocked_R (gsignal.c:2438) ==23441== by 0x4A11D82: g_signal_emit_valist (gsignal.c:2197) ==23441== by 0x4A12028: g_signal_emit (gsignal.c:2241) ==23441== by 0x8100607: redo_layout_internal (nautilus-icon-container.c:5614) ==23441== by 0x4A0CD42: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==23441== by 0x49FD738: g_type_class_meta_marshal (gclosure.c:567) ==23441== by 0x49FEFEB: g_closure_invoke (gclosure.c:490) ==23441== by 0x4A10D99: signal_emit_unlocked_R (gsignal.c:2368) ==23441== by 0x4A11D82: g_signal_emit_valist (gsignal.c:2197) ==23441== by 0x4A12028: g_signal_emit (gsignal.c:2241) ==23441== by 0x4522609: gtk_widget_size_allocate (gtkwidget.c:2878) ==23441== by 0x4470E22: gtk_scrolled_window_size_allocate (gtkscrolledwindow.c:1151) ==23441== by 0x4A0CD42: g_cclosure_marshal_VOID__BOXED (gmarshal.c:566) ==23441== by 0x49FD738: g_type_class_meta_marshal (gclosure.c:567) ==23441== by 0x49FEFEB: g_closure_invoke (gclosure.c:490)
Created attachment 60010 [details] [review] this patch helps. Kjartan, I like to use gtk-demo to test the bridge, but I can't valgrind it these days (gslice/gmemchunk or something?). How are you valgrinding?
I'm running valgrind on the entire session here. I'll test the patch soon.
The big leak is definitely still there after testing the last patch you sent me Bill: ==7808== 672 bytes in 8 blocks are definitely lost in loss record 4 of 12 ==7808== at 0x4004F52: malloc (vg_replace_malloc.c:149) ==7808== by 0x41191F5: g_malloc (gmem.c:131) ==7808== by 0x4116149: g_markup_parse_context_new (gmarkup.c:132) ==7808== by 0x44883D1: ??? ==7808== by 0x448A204: ??? ==7808== by 0x448A2C0: ??? ==7808== by 0x4484D7A: ??? ==7808== by 0x401D47D: gconf_sources_all_entries (gconf-sources.c:210) ==7808== by 0x804C165: gconf_database_all_entries (gconf-database.c:1617) ==7808== by 0x804DD4F: impl_ConfigDatabase2_all_entries_with_schema_name (gconf-database.c:618) ==7808== by 0x402C17C: _ORBIT_skel_small_ConfigDatabase2_all_entries_with_schema_name (GConfX-common.c:112) ==7808== by 0x4066C56: ORBit_POAObject_invoke (poa.c:1145) ==7808== by 0x406CDB4: ORBit_OAObject_invoke (orbit-adaptor.c:336) ==7808== by 0x4059E66: ORBit_small_invoke_adaptor (orbit-small.c:835) ==7808== by 0x406AA3D: ORBit_POAObject_handle_request (poa.c:1354) ==7808== by 0x406B0E1: ORBit_POAObject_invoke_incoming_request (poa.c:1422) ==7808== by 0x406BB52: ORBit_POA_handle_request (poa.c:1644) ==7808== by 0x406CF51: ORBit_handle_request (orbit-adaptor.c:296) ==7808== by 0x4056236: giop_connection_handle_input (giop-recv-buffer.c:1282) ==7808== by 0x4073AFC: link_connection_io_handler (linc-connection.c:1367) ==7808== by 0x40768CD: link_source_dispatch (linc-source.c:159) ==7808== by 0x4111BCC: g_main_context_dispatch (gmain.c:1916) ==7808== by 0x4114E4E: g_main_context_iterate (gmain.c:2547) ==7808== by 0x41151F8: g_main_loop_run (gmain.c:2751) ==7808== by 0x8051881: main (gconfd.c:934)
Kjartan: how can that possibly be the same leak? (in your latest stacktrace)... Did you perhaps post the wrong stacktrace, or are we missing some at-spi frames in there?
Sorry, cut'n'paste'o. I meant the one with hundreds of kb that is shown further up.
The first patch is toxic and should not be applied.
Created attachment 60262 [details] [review] this one works This patch was tested with valgrind using memcheck and leak-check, with the gnome-at-properties dialog and with the 'make check' test program; no at-spi leaks were detected (at least in code that executes more than once - there's a possible startup leak, but that's only hit once per app). The patch seems also not to regress at-spi-registryd, so I am applying it to cvs and to at-spi-1.7.6.
The atk-bridge/bridge.c part of the patch introduced problems like bug 334408 and bug 335719 - please look for a different solution, Ubuntu reverted this part of the patch.
I am positive that the bridge.c part of the patch is correct. Any problems it unearths must be elsewhere. I am closing this bug, but of course bug 334408 is open and a major concern. FWIW the problem isn't being reported on 64bit Solaris, odd.