GNOME Bugzilla – Bug 702027
gdbus memory leak
Last modified: 2013-06-12 09:23:32 UTC
==21714== 48 bytes in 3 blocks are definitely lost in loss record 3,308 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x376804D93E: g_malloc (gmem.c:159) ==21714== by 0x37680634ED: g_slice_alloc (gslice.c:1003) ==21714== by 0x3768063A2D: g_slice_alloc0 (gslice.c:1029) ==21714== by 0x3768045019: get_dispatch (gmain.c:2705) ==21714== by 0x3768047DA4: g_main_context_dispatch (gmain.c:2997) ==21714== by 0x37680481F7: g_main_context_iterate.isra.22 (gmain.c:3701) ==21714== by 0x37680485F9: g_main_loop_run (gmain.c:3895) ==21714== by 0x3CFD0B9512: g_dbus_connection_send_message_with_reply_sync (gdbusconnection.c:2240) ==21714== by 0x3CFD0B9946: g_dbus_connection_call_sync_internal (gdbusconnection.c:5564) ==21714== by 0x3CFD0C5322: g_dbus_proxy_call_sync_internal (gdbusproxy.c:2910) ==21714== by 0x3CFD0C6742: g_dbus_proxy_call_sync (gdbusproxy.c:3102) ==21714== Might need to run with a higher value for --num-callers to make sense of this one?
A bunch of these in the addressbook-factory too: ==31079== 16 bytes in 1 blocks are definitely lost in loss record 1,716 of 6,319 ==31079== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31079== by 0x376804D93E: g_malloc (gmem.c:159) ==31079== by 0x37680634ED: g_slice_alloc (gslice.c:1003) ==31079== by 0x3768063A2D: g_slice_alloc0 (gslice.c:1029) ==31079== by 0x3768045019: get_dispatch (gmain.c:2705) ==31079== by 0x3768047DA4: g_main_context_dispatch (gmain.c:2997) ==31079== by 0x37680481F7: g_main_context_iterate.isra.22 (gmain.c:3701) ==31079== by 0x37680485F9: g_main_loop_run (gmain.c:3895) ==31079== by 0x3CFD0C6B95: gdbus_shared_thread_func (gdbusprivate.c:278) ==31079== by 0x376806C224: g_thread_proxy (gthread.c:798) ==31079== by 0x3909607C52: start_thread (pthread_create.c:308) ==31079== by 0x39092F4ECC: clone (clone.S:113) ==31079== 16 bytes in 1 blocks are definitely lost in loss record 1,717 of 6,319 ==31079== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31079== by 0x376804D93E: g_malloc (gmem.c:159) ==31079== by 0x37680634ED: g_slice_alloc (gslice.c:1003) ==31079== by 0x3768063A2D: g_slice_alloc0 (gslice.c:1029) ==31079== by 0x3768045019: get_dispatch (gmain.c:2705) ==31079== by 0x3768047288: g_main_current_source (gmain.c:2847) ==31079== by 0x3CFD077D8C: g_task_return (gtask.c:1150) ==31079== by 0x3CFD077F1C: g_task_thread_pool_thread (gtask.c:1244) ==31079== by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309) ==31079== by 0x376806C224: g_thread_proxy (gthread.c:798) ==31079== by 0x3909607C52: start_thread (pthread_create.c:308) ==31079== by 0x39092F4ECC: clone (clone.S:113) ==31079== 16 bytes in 1 blocks are definitely lost in loss record 1,718 of 6,319 ==31079== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31079== by 0x376804D93E: g_malloc (gmem.c:159) ==31079== by 0x37680634ED: g_slice_alloc (gslice.c:1003) ==31079== by 0x3768063A2D: g_slice_alloc0 (gslice.c:1029) ==31079== by 0x3768045019: get_dispatch (gmain.c:2705) ==31079== by 0x3768047DA4: g_main_context_dispatch (gmain.c:2997) ==31079== by 0x37680481F7: g_main_context_iterate.isra.22 (gmain.c:3701) ==31079== by 0x37680485F9: g_main_loop_run (gmain.c:3895) ==31079== by 0x3CFD0B9512: g_dbus_connection_send_message_with_reply_sync (gdbusconnection.c:2240) ==31079== by 0x3CFD0B9946: g_dbus_connection_call_sync_internal (gdbusconnection.c:5564) ==31079== by 0x3CFD0C5322: g_dbus_proxy_call_sync_internal (gdbusproxy.c:2910) ==31079== by 0x3CFD0C6742: g_dbus_proxy_call_sync (gdbusproxy.c:3102)
This is the same valgrind bug as in bug 702021 and bug 702023. This is another thread-local variable which *is* correctly freed when the thread exits.