I can repro this 100% of the time by enabling wireless, connecting to my 802.11n router, disconnecting from the wired network, and leaving the computer on for a long time. 1 day seems to be sufficient. After that, the NM applet becomes unresponsive--clicking on any menu item does nothing, and the submenus are empty. OTOH, the wireless connection continues to work.
Killing and restarting nm-applet fixes the problem. There seems to be no need to restart the network-manager service.
In my "normal" day-to-day activities I leave wireless disabled and I leave the computer in sleep mode most of the time, which does NOT repro this.
Memory usage of nm-applet in top while unresponsive:
Backtrace of all threads in nm-applet while unresponsive:
(gdb) thread apply all bt
Thread 3 (Thread 0x7f2ada61d700 (LWP 1986)):
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f2adae5e98b in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4 0x00007f2ae24449a5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f2ae2b48e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f2ae1ee94bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7f2ad8dab700 (LWP 1991)):
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f2ae39432c6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4 0x00007f2ae24449a5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f2ae2b48e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f2ae1ee94bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7f2ae4f17980 (LWP 1980)):
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x0000000000414267 in main (argc=1, argv=0x7fffc4aac088) at main.c:106
Memory usage of nm-applet in top after restarting it:
Almost identical numbers, so clearly the bug has nothing to do with leaks in nm-applet.
Backtrace of all threads in nm-applet after restarting it:
(gdb) thread apply all bt
Thread 3 (Thread 0x7fe01d188700 (LWP 6245)):
#0 0x00007fe024a48b03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fe024f8dff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fe024f8e45a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007fe01d9c998b in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4 0x00007fe024faf9a5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007fe0256b3e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007fe024a544bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7fe0177b1700 (LWP 6246)):
#0 0x00007fe024a48b03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fe024f8dff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fe024f8e45a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007fe0264ae2c6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4 0x00007fe024faf9a5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007fe0256b3e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007fe024a544bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7fe027a82980 (LWP 6244)):
#0 0x00007fe024a48b03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fe024f8dff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fe024f8e45a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x0000000000414267 in main (argc=1, argv=0x7fff28c08c18) at main.c:106
Also no different, so there does not seem to be any obvious hang in the nm-applet process.
Curiously, when this happened today I found that Update Manager was open with 3 updates available, and it was also unresponsive--clicking on it in the launcher did not display the window and I also could not Alt+Tab to it. gdb showed no obvious hangs in the update-manager Python process either. Could be related (but not the root cause, since running Update Manager manually did not repro the problem).
Some more information:
I can repro this 100% of the time by enabling wireless, connecting to my 802.11n router, disconnecting from the wired network, and leaving the computer on for a long time. 1 day seems to be sufficient. After that, the NM applet becomes unresponsive- -clicking on any menu item does nothing, and the submenus are empty. OTOH, the wireless connection continues to work.
Killing and restarting nm-applet fixes the problem. There seems to be no need to restart the network-manager service.
In my "normal" day-to-day activities I leave wireless disabled and I leave the computer in sleep mode most of the time, which does NOT repro this.
Memory usage of nm-applet in top while unresponsive:
1980 tristan 20 0 624m 23m 12m S 0 0.3 1:02.16 nm-applet
Backtrace of all threads in nm-applet while unresponsive:
(gdb) thread apply all bt
Thread 3 (Thread 0x7f2ada61d700 (LWP 1986)): 64-linux- gnu/libc. so.6 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 x86_64- linux-gnu/ gio/modules/ libdconfsetting s.so 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libpthread. so.0 64-linux- gnu/libc. so.6
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_
#3 0x00007f2adae5e98b in ?? () from /usr/lib/
#4 0x00007f2ae24449a5 in ?? () from /lib/x86_
#5 0x00007f2ae2b48e9a in start_thread () from /lib/x86_
#6 0x00007f2ae1ee94bd in clone () from /lib/x86_
#7 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7f2ad8dab700 (LWP 1991)): 64-linux- gnu/libc. so.6 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 x86_64- linux-gnu/ libgio- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libpthread. so.0 64-linux- gnu/libc. so.6
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_
#3 0x00007f2ae39432c6 in ?? () from /usr/lib/
#4 0x00007f2ae24449a5 in ?? () from /lib/x86_
#5 0x00007f2ae2b48e9a in start_thread () from /lib/x86_
#6 0x00007f2ae1ee94bd in clone () from /lib/x86_
#7 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7f2ae4f17980 (LWP 1980)): 64-linux- gnu/libc. so.6 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 c088) at main.c:106
#0 0x00007f2ae1eddb03 in poll () from /lib/x86_
#1 0x00007f2ae2422ff6 in ?? () from /lib/x86_
#2 0x00007f2ae242345a in g_main_loop_run () from /lib/x86_
#3 0x0000000000414267 in main (argc=1, argv=0x7fffc4aa
Memory usage of nm-applet in top after restarting it:
6244 tristan 20 0 618m 17m 11m S 0 0.2 0:00.33 nm-applet
Almost identical numbers, so clearly the bug has nothing to do with leaks in nm-applet.
Backtrace of all threads in nm-applet after restarting it:
(gdb) thread apply all bt
Thread 3 (Thread 0x7fe01d188700 (LWP 6245)): 64-linux- gnu/libc. so.6 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 x86_64- linux-gnu/ gio/modules/ libdconfsetting s.so 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libpthread. so.0 64-linux- gnu/libc. so.6
#0 0x00007fe024a48b03 in poll () from /lib/x86_
#1 0x00007fe024f8dff6 in ?? () from /lib/x86_
#2 0x00007fe024f8e45a in g_main_loop_run () from /lib/x86_
#3 0x00007fe01d9c998b in ?? () from /usr/lib/
#4 0x00007fe024faf9a5 in ?? () from /lib/x86_
#5 0x00007fe0256b3e9a in start_thread () from /lib/x86_
#6 0x00007fe024a544bd in clone () from /lib/x86_
#7 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7fe0177b1700 (LWP 6246)): 64-linux- gnu/libc. so.6 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 x86_64- linux-gnu/ libgio- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libpthread. so.0 64-linux- gnu/libc. so.6
#0 0x00007fe024a48b03 in poll () from /lib/x86_
#1 0x00007fe024f8dff6 in ?? () from /lib/x86_
#2 0x00007fe024f8e45a in g_main_loop_run () from /lib/x86_
#3 0x00007fe0264ae2c6 in ?? () from /usr/lib/
#4 0x00007fe024faf9a5 in ?? () from /lib/x86_
#5 0x00007fe0256b3e9a in start_thread () from /lib/x86_
#6 0x00007fe024a544bd in clone () from /lib/x86_
#7 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7fe027a82980 (LWP 6244)): 64-linux- gnu/libc. so.6 64-linux- gnu/libglib- 2.0.so. 0 64-linux- gnu/libglib- 2.0.so. 0 8c18) at main.c:106
#0 0x00007fe024a48b03 in poll () from /lib/x86_
#1 0x00007fe024f8dff6 in ?? () from /lib/x86_
#2 0x00007fe024f8e45a in g_main_loop_run () from /lib/x86_
#3 0x0000000000414267 in main (argc=1, argv=0x7fff28c0
Also no different, so there does not seem to be any obvious hang in the nm-applet process.
Curiously, when this happened today I found that Update Manager was open with 3 updates available, and it was also unresponsive- -clicking on it in the launcher did not display the window and I also could not Alt+Tab to it. gdb showed no obvious hangs in the update-manager Python process either. Could be related (but not the root cause, since running Update Manager manually did not repro the problem).