/usr/lib/indicator-appmenu/hud-service at 100% CPU when skype is running and the connection cuts off

Bug #1045262 reported by Santiago Gala
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Application Menu Indicator
New
Undecided
Unassigned
skype
New
Undecided
Unassigned
sni-qt
New
Undecided
Unassigned
indicator-appmenu (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I found this to be draining my batteries: when I switch skype on in a wifi cafe to talk, and then forget to close it before moving, indicator-appmenu, and specifically the hud-service, spins taking 100% cpu until skype is closed.

I report the bug here as skype is **not** the process spinning, and it behaves as it used to (with a changing grey icon since it is able to recover a connection).

Revision history for this message
Santiago Gala (sgala) wrote :

It might be relevant or not, but I'm running amd64 architecture, and skype is 32 bits. I see those messages when I start skype from a terminal:

 /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: clase ELF errónea: ELFCLASS64

(skype:19555): Gtk-WARNING **: Failed to load type module: /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so

/usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: clase ELF errónea: ELFCLASS64

(skype:19555): Gtk-WARNING **: Failed to load type module: /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so

/usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: clase ELF errónea: ELFCLASS64

(skype:19555): Gtk-WARNING **: Failed to load type module: /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so

/usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so: clase ELF errónea: ELFCLASS64

(skype:19555): Gtk-WARNING **: Failed to load type module: /usr/lib/gtk-2.0/2.10.0/menuproxies/libappmenu.so

Revision history for this message
Omer Akram (om26er) wrote :

confirmed. That's similar to the issue with indicator-multiload. more on bug 784055 and bug 813409

Revision history for this message
Santiago Gala (sgala) wrote :

It is not a duplicate, as it is ***not*** compiz spinning, but hud-service. Those bugs are about compiz sending expose events, here there is no graphics related activity

Revision history for this message
Omer Akram (om26er) wrote :

*THAT'S ALL THE SAME*

Revision history for this message
Bilal Akhtar (bilalakhtar) wrote :

Sni-qt could be related to this.

Revision history for this message
Philip Aston (philipa) wrote :

I see this too on Ubuntu 13.04.

strace says that hud-service is continually spining:

access("/usr/share/indicator-appmenu/hud/app-info/skype.hud-app-info", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/indicator-appmenu/hud/app-info/skype.hud-app-info", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/indicator-appmenu/hud/app-info/skype.hud-app-info", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/indicator-appmenu/hud/app-info/skype.hud-app-info", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/share/indicator-appmenu/hud/app-info/skype.hud-app-info", F_OK) = -1 ENOENT (No such file or directory)
...

The /usr/share/indicator-appmenu directory does not exist

Revision history for this message
Axel G. Rossberg (axel-rossberg) wrote :

Same problem here, with Ubuntu 12.04 and now 13.04.

Important to reproduce the bug: In my case the problem occurs only when there is no internet connection. With internet, hud-service seems to calm down gradually. This is why I believe that the hud-service activity is triggered by skype as skype is trying to find and connect to the network.

Revision history for this message
Axel G. Rossberg (axel-rossberg) wrote :

The system calls of hud-service noted in #6 seem to be generated in check_app_init or configure_db here http://sourcecodebrowser.com/indicator-appmenu/12.10.0/usage-tracker_8c.html .

The calls in configure_db I would not expect to be executed after doing

gsettings set com.canonical.indicator.appmenu.hud store-usage-data false

Since I see the system calls even after this when running

killall hud-service; strace /usr/lib/x86_64-linux-gnu/hud/hud-service

I assume the calls in check_app_init are to blame. This is, however, where my understanding of the problem ends.

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

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

Changed in indicator-appmenu (Ubuntu):
status: New → Confirmed
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.