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

[Santiago Gala]

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)]

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)]

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

[Santiago Gala (sgala)]

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)]

*THAT'S ALL THE SAME*

[Bilal Akhtar (bilalakhtar)]

Sni-qt could be related to this.

[Philip Aston (philipa)]

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

[Axel G. Rossberg (axel-rossberg)]

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.

[Axel G. Rossberg (axel-rossberg)]

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)]

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