nm-applet becomes unresponsive to interactions and submenus such as 'VPN Connections' show completely empty

Bug #1117730 reported by James M. Leddy
210
This bug affects 39 people
Affects Status Importance Assigned to Milestone
DBus Menu
New
Undecided
Unassigned
OEM Priority Project
Triaged
Medium
James M. Leddy
Precise
Triaged
Medium
James M. Leddy
Quantal
Triaged
Medium
James M. Leddy
Raring
Triaged
Medium
James M. Leddy
libdbusmenu (Ubuntu)
Triaged
Undecided
Charles Kerr
Nominated for Precise by James M. Leddy
Nominated for Quantal by James M. Leddy
Nominated for Raring by James M. Leddy
network-manager-applet (Ubuntu)
Confirmed
Undecided
Mathieu Trudel-Lapierre
Nominated for Precise by James M. Leddy
Nominated for Quantal by James M. Leddy
Nominated for Raring by James M. Leddy

Bug Description

broken out of bug 780602, because we believe the root cause to be different. From that bug report:

I experience exactly the same symptoms as the bug report description has.

After some time nm-applet stops reacting to user input and submenu entries do not populate. This is with latest 12.10 packages.

I noticed that the indicator tries to get the menu but it fails - dbus-monitor output below:
method call sender=:1.12 -> dest=:1.67 serial=14296 path=/com/canonical/Unity/Panel/Service; interface=com.canonical.Unity.Panel.Service; member=ShowEntry
   string "0x26ef470"
   uint32 0
   int32 1147
   int32 24
   uint32 1
   uint32 1356027813
method return sender=:1.67 -> dest=:1.12 reply_serial=14296
method call sender=:1.67 -> dest=:1.14 serial=107621 path=/org/ayatana/NotificationItem/nm_applet/Menu; interface=com.canonical.dbusmenu; member=AboutToShowGroup
   array [
      int32 80799
   ]
error sender=:1.14 -> dest=:1.67 error_name=org.gtk.GDBus.UnmappedGError.Quark._LIBDBUSMENU_2dGLIB.Code0 reply_serial=107621
   string "The IDs supplied '[80799]' do not refer to any menu items we have"

When some item is clicked (e.g. disconnect for current wifi AP) the following happens:
signal sender=:1.67 -> dest=(null destination) serial=107704 path=/com/canonical/Unity/Panel/Service; interface=com.canonical.Unity.Panel.Service; member=EntryActivated
   string ""
   struct {
      int32 0
      int32 0
      uint32 0
      uint32 0
   }
method call sender=:1.67 -> dest=:1.14 serial=107705 path=/org/ayatana/NotificationItem/nm_applet/Menu; interface=com.canonical.dbusmenu; member=EventGroup
   array [
      struct {
         int32 80846
         string "clicked"
         variant int32 0
         uint32 106251172
      }
   ]
error sender=:1.14 -> dest=:1.67 error_name=org.gtk.GDBus.UnmappedGError.Quark._LIBDBUSMENU_2dGLIB.Code0 reply_serial=107705
   string "The IDs supplied '[80846]' do not refer to any menu items we have"

So this looks like like dbus menu is losing the IDs or nm-applet is using the ids that are no longer valid.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager-applet (Ubuntu):
status: New → Confirmed
Martin Spacek (mspacek)
summary: nm-applet becomes unresponsive to interactions and submenus such as 'VPN
- Connections' show completly empty
+ Connections' show completely empty
Revision history for this message
Marlon Nelson (marlon-nelson) wrote :

Could this bug be a symptom of (or masking) malware?

I only ask because I've been experiencing the bug for over a year, and in more than one release. It's been interesting watching it being kicked around system but never fixed.

I think it's a critical bug and needs to be fixed ASAP, since it breaks an important part of the system and prevents ordinary users (i.e. those unwilling/unable to open a terminal window and issue the commands to fix the situation) from doing things like connecting to a VPN, checking what WiFi connection is being used, switching to a different WiFi network, etc.

Is it possible there are people with an interest in keeping this bug in-place? Maybe I'm being too paranoid.

Changed in libdbusmenu (Ubuntu):
assignee: nobody → Charles Kerr (charlesk)
status: New → Triaged
Changed in network-manager-applet (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
James M. Leddy (jm-leddy) wrote :

Mathieu has posted some debug packages in bug 780602 that should give us more info in order to solve the bug.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

We don't need so much additional information anymore from the debug packages.

I was able to write a small python script that reproduces the issue:
https://code.launchpad.net/~mathieu-tl/+junk/test-indicator-update

Playing with the delays there and the number of updates in a row, you can easily wedge dbusmenu in a matter of about an hour.

As far as I'm concerned, this proves that the issue isn't in nm-applet but somewhere in the way that dbusmenu takes care of updates to the menus, but I'm still not quite sure what is wong with it.

Any help is of course welcome :)

Revision history for this message
Koopee (koopee1234) wrote :

How about ubuntu version? I'm experiencing this issue with amd64 version. Does anyone have this problem with 32 bit ubuntu?

Revision history for this message
Catalin Patulea (cpatulea) wrote :

test-update.py as it is in the repo doesn't trigger it for me. The submenu still expands with the current menuitem. While keeping it open, the menu disappears and re-appears with the new menuitem.

How should I tweak the delays to make it easier to reproduce?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.