GNOME Bugzilla – Bug 629684
mem leak in gdbus-export test
Last modified: 2017-10-26 10:17:17 UTC
I've been unable to track this down, so I'm posting it here for you :) ==6531== 156 (48 direct, 108 indirect) bytes in 2 blocks are definitely lost in loss record 1,040 of 1,131 ==6531== at 0x4005BDC: malloc (vg_replace_malloc.c:195) ==6531== by 0x4056B74: g_malloc (gmem.c:164) ==6531== by 0x406EDB6: g_slice_alloc (gslice.c:842) ==6531== by 0x4091A4E: g_variant_alloc (gvariant-core.c:475) ==6531== by 0x4091ACF: g_variant_new_from_buffer (gvariant-core.c:507) ==6531== by 0x408AF1F: g_variant_new_from_trusted (gvariant.c:311) ==6531== by 0x408C0E3: g_variant_new_string (gvariant.c:992) ==6531== by 0x420FC91: parse_value_from_blob (gdbusmessage.c:1208) ==6531== by 0x4210548: parse_value_from_blob (gdbusmessage.c:1479) ==6531== by 0x42103AE: parse_value_from_blob (gdbusmessage.c:1428) ==6531== by 0x4210DF0: g_dbus_message_new_from_blob (gdbusmessage.c:1778) ==6531== by 0x421C383: _g_dbus_worker_do_read_cb (gdbusprivate.c:696) ==6531== by 0x41BB278: g_simple_async_result_complete (gsimpleasyncresult.c:818) ==6531== by 0x41BB2B4: complete_in_idle_cb (gsimpleasyncresult.c:828) ==6531== by 0x40522B4: g_idle_dispatch (gmain.c:4254) ==6531== by 0x404E805: g_main_dispatch (gmain.c:2149) ==6531== by 0x404FAF9: g_main_context_dispatch (gmain.c:2702) ==6531== by 0x404FF4E: g_main_context_iterate (gmain.c:2780) ==6531== by 0x40506B7: g_main_loop_run (gmain.c:2988) ==6531== by 0x421B821: shared_thread_func (gdbusprivate.c:248) ==6531== by 0x407C190: g_thread_create_proxy (gthread.c:1897) ==6531== by 0x57D918: start_thread (pthread_create.c:301) ==6531== by 0x4C6CBD: clone (clone.S:133) and a similar one from the gdbus-peer test: ==7269== 57 (24 direct, 33 indirect) bytes in 1 blocks are definitely lost in loss record 1,173 of 1,325 ==7269== at 0x4005BDC: malloc (vg_replace_malloc.c:195) ==7269== by 0x4056B74: g_malloc (gmem.c:164) ==7269== by 0x406EDB6: g_slice_alloc (gslice.c:842) ==7269== by 0x4091A4E: g_variant_alloc (gvariant-core.c:475) ==7269== by 0x4091ACF: g_variant_new_from_buffer (gvariant-core.c:507) ==7269== by 0x408AF1F: g_variant_new_from_trusted (gvariant.c:311) ==7269== by 0x408C0E3: g_variant_new_string (gvariant.c:992) ==7269== by 0x420FC91: parse_value_from_blob (gdbusmessage.c:1208) ==7269== by 0x4210548: parse_value_from_blob (gdbusmessage.c:1479) ==7269== by 0x42102BC: parse_value_from_blob (gdbusmessage.c:1392) ==7269== by 0x4210130: parse_value_from_blob (gdbusmessage.c:1339) ==7269== by 0x42103AE: parse_value_from_blob (gdbusmessage.c:1428) ==7269== by 0x4210DF0: g_dbus_message_new_from_blob (gdbusmessage.c:1778) ==7269== by 0x421C383: _g_dbus_worker_do_read_cb (gdbusprivate.c:696) ==7269== by 0x41BB278: g_simple_async_result_complete (gsimpleasyncresult.c:818) ==7269== by 0x41BB2B4: complete_in_idle_cb (gsimpleasyncresult.c:828) ==7269== by 0x40522B4: g_idle_dispatch (gmain.c:4254) ==7269== by 0x404E805: g_main_dispatch (gmain.c:2149) ==7269== by 0x404FAF9: g_main_context_dispatch (gmain.c:2702) ==7269== by 0x404FF4E: g_main_context_iterate (gmain.c:2780) ==7269== by 0x40506B7: g_main_loop_run (gmain.c:2988) ==7269== by 0x421B821: shared_thread_func (gdbusprivate.c:248) ==7269== by 0x407C190: g_thread_create_proxy (gthread.c:1897) ==7269== by 0x57D918: start_thread (pthread_create.c:301) ==7269== by 0x4C6CBD: clone (clone.S:133)
Created attachment 188233 [details] [review] move unrefs to dispose
Sorry, My comments on the patch above got lost. It looks like the problem is that the message object violates the gobject memory management contract. References are supposed to be released in dispose, not finalize. http://developer.gnome.org/gobject/stable/gobject-memory.html It is possible this is also causing https://bugzilla.gnome.org/show_bug.cgi?id=638335
Having done further testing, that patch does not fix the problem.
The real problem with gdbus-export.c starts at line 845: g_variant_get (value, "(v)", &inner); The "inner" variant reference never gets unrefed. The other issue is probably something similar.
Neither test seems to leak any more. Potentially fixed by bug #711802.