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

Bug #1045262 reported by Santiago Gala on 2012-09-03
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)
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).

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

Omer Akram (om26er) wrote :

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

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

Omer Akram (om26er) wrote :

*THAT'S ALL THE SAME*

Bilal Akhtar (bilalakhtar) wrote :

Sni-qt could be related to this.

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

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.

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.

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  Edit
Everyone can see this information.

Other bug subscribers