So far the leaks identified in the bugs I filed above are relatively small, and they don't account for the massive leaks I am seeing. Each time I disable and then re-enable the wireless using hotkeys, it causes nm-applet to consume between 300K and 500K of additional memory. The memory grows at a regular rate even if I do nothing, and in just a few minutes it jumped another MB or so.
The leak identified in log entry below is on the right order of magnitude, but I cannot tell where the leak actually is.
==10301== 111,377 (5,520 direct, 105,857 indirect) bytes in 138 blocks are definitely lost in loss record 9,321 of 9,326
==10301== at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==10301== by 0x8F62A62: g_malloc (gmem.c:164)
==10301== by 0x8F79666: g_slice_alloc (gslice.c:842)
==10301== by 0x8F97A09: g_variant_alloc (gvariant-core.c:475)
==10301== by 0x8F97B0C: g_variant_new_from_children (gvariant-core.c:560)
==10301== by 0x8F9532D: g_variant_builder_end (gvariant.c:3260)
==10301== by 0x6D1D9A7: parse_value_from_blob (gdbusmessage.c:1447)
==10301== by 0x6D1DABE: parse_value_from_blob (gdbusmessage.c:1431)
==10301== by 0x6D1F0BD: g_dbus_message_new_from_blob (gdbusmessage.c:1781)
==10301== by 0x6D27FF4: _g_dbus_worker_do_read_cb (gdbusprivate.c:737)
==10301== by 0x6CD6D48: complete_in_idle_cb (gsimpleasyncresult.c:757)
==10301== by 0x8F5BBCC: g_main_context_dispatch (gmain.c:2440)
==10301== by 0x8F5C3A7: g_main_context_iterate.clone.6 (gmain.c:3091)
==10301== by 0x8F5C9F1: g_main_loop_run (gmain.c:3299)
==10301== by 0x6D26C43: gdbus_shared_thread_func (gdbusprivate.c:276)
==10301== by 0x8F833E3: g_thread_create_proxy (gthread.c:1897)
==10301== by 0x86A3D8B: start_thread (pthread_create.c:304)
==10301== by 0x92EE04C: clone (clone.S:112)
This thread is started when a g_dbus_worker is created.
For some reason dbus messages (message bodies in particular) are not getting cleaned up properly.
I checked Fedora 15, and this problem does not happen there. So the problem must be in the Ubuntu-specific modifications to nm-applet (appindicator, etc.).
So far the leaks identified in the bugs I filed above are relatively small, and they don't account for the massive leaks I am seeing. Each time I disable and then re-enable the wireless using hotkeys, it causes nm-applet to consume between 300K and 500K of additional memory. The memory grows at a regular rate even if I do nothing, and in just a few minutes it jumped another MB or so.
The leak identified in log entry below is on the right order of magnitude, but I cannot tell where the leak actually is.
==10301== 111,377 (5,520 direct, 105,857 indirect) bytes in 138 blocks are definitely lost in loss record 9,321 of 9,326 malloc. c:236) core.c: 475) new_from_ children (gvariant- core.c: 560) builder_ end (gvariant.c:3260) from_blob (gdbusmessage. c:1447) from_blob (gdbusmessage. c:1431) message_ new_from_ blob (gdbusmessage. c:1781) worker_ do_read_ cb (gdbusprivate. c:737) sult.c: 757) context_ dispatch (gmain.c:2440) context_ iterate. clone.6 (gmain.c:3091) thread_ func (gdbusprivate. c:276) create_ proxy (gthread.c:1897) create. c:304)
==10301== at 0x4C28FAC: malloc (vg_replace_
==10301== by 0x8F62A62: g_malloc (gmem.c:164)
==10301== by 0x8F79666: g_slice_alloc (gslice.c:842)
==10301== by 0x8F97A09: g_variant_alloc (gvariant-
==10301== by 0x8F97B0C: g_variant_
==10301== by 0x8F9532D: g_variant_
==10301== by 0x6D1D9A7: parse_value_
==10301== by 0x6D1DABE: parse_value_
==10301== by 0x6D1F0BD: g_dbus_
==10301== by 0x6D27FF4: _g_dbus_
==10301== by 0x6CD6D48: complete_in_idle_cb (gsimpleasyncre
==10301== by 0x8F5BBCC: g_main_
==10301== by 0x8F5C3A7: g_main_
==10301== by 0x8F5C9F1: g_main_loop_run (gmain.c:3299)
==10301== by 0x6D26C43: gdbus_shared_
==10301== by 0x8F833E3: g_thread_
==10301== by 0x86A3D8B: start_thread (pthread_
==10301== by 0x92EE04C: clone (clone.S:112)
This thread is started when a g_dbus_worker is created.
http:// git.gnome. org/browse/ glib/tree/ gio/gdbusprivat e.c
For some reason dbus messages (message bodies in particular) are not getting cleaned up properly.
I checked Fedora 15, and this problem does not happen there. So the problem must be in the Ubuntu-specific modifications to nm-applet (appindicator, etc.).