Leak in appmenu-gtk

[Mathieu Trudel-Lapierre]

Binary package hint: indicator-application

This is a *may have been found* because I'm not 100% certain it's not nm-applet patch to use libappindicator which actually leaks, but I have reason to believe this is an issue in libappindicator:

==25714== 8 bytes in 1 blocks are definitely lost in loss record 1,720 of 7,879
==25714== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==25714== by 0x48255C3: g_malloc (gmem.c:164)
==25714== by 0x4825902: g_malloc_n (gmem.c:381)
==25714== by 0x47C839A: g_type_children (gtype.c:3512)
==25714== by 0x4284C6D: ubuntu_menu_proxy_module_get (ubuntumenuproxymodule.c:155)
==25714== by 0x428465C: ubuntu_menu_proxy_get (ubuntumenuproxy.c:199)
==25714== by 0x4285E45: gtk_menu_shell_init (gtkmenushell.c:448)
==25714== by 0x47C8FD4: g_type_create_instance (gtype.c:1879)
==25714== by 0x47A4C54: g_object_constructor (gobject.c:1602)
==25714== by 0x47A8326: g_object_newv (gobject.c:1386)
==25714== by 0x47A900F: g_object_new (gobject.c:1298)
==25714== by 0x427A4A6: gtk_menu_new (gtkmenu.c:1313)

==25714== 50 bytes in 1 blocks are definitely lost in loss record 5,699 of 7,879
==25714== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==25714== by 0x48255C3: g_malloc (gmem.c:164)
==25714== by 0x483F486: g_strconcat (gstrfuncs.c:327)
==25714== by 0x4C2BC59: g_module_build_path (gmodule-dl.c:161)
==25714== by 0x428CFB3: _gtk_find_module (gtkmodules.c:202)
==25714== by 0x4284A3C: ubuntu_menu_proxy_module_real_load (ubuntumenuproxymodule.c:95)
==25714== by 0x47CC323: g_type_module_use (gtypemodule.c:256)
==25714== by 0x4284C55: ubuntu_menu_proxy_module_get (ubuntumenuproxymodule.c:188)
==25714== by 0x428465C: ubuntu_menu_proxy_get (ubuntumenuproxy.c:199)
==25714== by 0x4285E45: gtk_menu_shell_init (gtkmenushell.c:448)
==25714== by 0x47C8FD4: g_type_create_instance (gtype.c:1879)
==25714== by 0x47A4C54: g_object_constructor (gobject.c:1602)

==25714== 10,224 bytes in 1,278 blocks are definitely lost in loss record 7,714 of 7,879
==25714== at 0x4024F12: calloc (vg_replace_malloc.c:467)
==25714== by 0x482563B: g_malloc0 (gmem.c:196)
==25714== by 0x5A77793: ??? (in /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so)
==25714== by 0x5A789B1: ??? (in /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so)
==25714== by 0x4284702: ubuntu_menu_proxy_insert (ubuntumenuproxy.c:227)
==25714== by 0x4285FAE: gtk_menu_shell_insert (gtkmenushell.c:566)
==25714== by 0x428601F: gtk_menu_shell_append (gtkmenushell.c:536)
==25714== by 0x805EA48: ??? (in /usr/bin/nm-applet)
==25714== by 0x481FE0B: g_timeout_dispatch (gmain.c:3688)
==25714== by 0x481E4E7: g_main_context_dispatch (gmain.c:2267)
==25714== by 0x481ECAF: g_main_context_iterate.clone.5 (gmain.c:2902)
==25714== by 0x481F372: g_main_loop_run (gmain.c:3110)

I'm not certain, and I'm certainly no valgrind wizard, but I believe that due to nm-applet building a fairly complex menu with label menuitems with markup, GtkImageMenuItems, and custom widgets implementing GtkMenuItem; along with the fact that the menus are being destroyed and rebuilt every 15 seconds, some of the data not used by libappindicator is not properly handled and leads to memory leaks.

[Ted Gould (ted)]

indicator-application doesn't use the menu_proxy interface, that is used by appmenu-gtk. Moving this over to that project.

[Eric Appleman (erappleman)]

This needs immediate attention.

[wyz (wangyizhuo)]

It rised to 220M after 3 hours' uptime.

[Mathieu Trudel-Lapierre (cyphermox)]

Eric, wyz,

Please make sure you're using the most up-to-date version of nm-applet (the network-manager-gnome package), this is no longer as much a problem as it was before; and in fact, this bug should be closed.

[bardic (bardic-knowledge)]

Hello all,
According to the update manager, my 10.10 install is currently all up to date. After about 2-3 days of uptime my nm-applet process is using 1.7gb of memory. Where can I find the latest patch for this?

Thanks,
TJ

[Kalle Valo (kvalo)]

The valgrind report seems valid so mark this bug as triaged.

Mathieu, I assume that there still is a memory leak in appmenu. If not, feel free to close this.

[shadow (mortalhate)]

i am using a nm-applet with my vodafone mobile modem. after disconnecting from the internet, my cpu usage gets crazy. 1st cpu is used 100% (hell) and second 15% and on the system tray one more icon is added. after that my laptop freezes.

caveman@noMoreMrNiceGuy:~$ uname -a
Linux noMoreMrNiceGuy 2.6.35-29-generic #51-Ubuntu SMP Fri Apr 15 17:13:54 UTC 2011 i686 i686 i386 GNU/Linux

if you need more information you may get in touch with me.

best.

[Mathieu Trudel-Lapierre (cyphermox)]

AFAICT, we can mark this a duplicate of newer bug 787736, which has been nicely analysed by JKL and has a provided patch. There are multiple other leaks in related libs that affect nm-applet though, and those are tracked in bug 780602.

[max ulidtko (ulidtko)]

I feel the need to share this stacktrace here despite the discussion in bug #787736. The stacktrace has been produced by using valgrind on the Pidgin application on Ubuntu 11.10:

==00:01:15:48.845 663== 448 bytes in 56 blocks are definitely lost in loss record 5,941 of 7,173
==00:01:15:48.849 663== at 0x402732C: calloc (vg_replace_malloc.c:467)
==00:01:15:48.850 663== by 0x48C85E2: standard_calloc (gmem.c:107)
==00:01:15:48.852 663== by 0x48C8DD9: g_malloc0 (gmem.c:196)
==00:01:15:48.852 663== by 0x804007B: ??? (in /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so)
==00:01:15:48.852 663== by 0x8040F7A: ??? (in /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so)
==00:01:15:48.852 663== by 0x4309375: ubuntu_menu_proxy_insert (ubuntumenuproxy.c:227)
==00:01:15:48.852 663== by 0x430AA79: gtk_menu_shell_insert (gtkmenushell.c:558)
==00:01:15:48.852 663== by 0x430AAEE: gtk_menu_shell_append (gtkmenushell.c:528)
==00:01:15:48.852 663== by 0x80809DC: update_menu_bar (gtkblist.c:4496)
==00:01:15:48.852 663== by 0x8084B4F: pidgin_blist_show (gtkblist.c:6017)
==00:01:15:48.852 663== by 0x49AF19E: purple_blist_show (blist.c:814)
==00:01:15:48.852 663== by 0x80CEBFF: main (gtkmain.c:875)

This looks very similar to one of stacktraces posted earlier by Mathieu and clearly suggests a leak inside libappmenu.