hud-service is eating up 100% of one of my CPUs in a poll loop

Bug #1300722 reported by Colin Ian King on 2014-04-01
286
This bug affects 63 people
Affects Status Importance Assigned to Milestone
unbuntu-fr Scripts - apt
Critical
Unassigned
hud (Ubuntu)
Critical
Unassigned

Bug Description

hud-service is polling like crazy:

Context Switches:
  PID Process Voluntary Involuntary Total
                             Ctxt Sw/Sec Ctxt Sw/Sec Ctxt Sw/Sec
  2295 hud-service 46084.63 42.94 46127.58 (very high)
  2325 hud-service 0.09 0.00 0.09 (very low)
  2329 hud-service 0.07 0.00 0.07 (very low)
  2340 hud-service 0.05 0.00 0.05 (very low)
 Total 46084.84 42.94 46127.78

File I/O operations:
 No file I/O operations detected.

System calls traced:
  PID Process Syscall Count Rate/Sec
  2295 hud-service poll 999983 23124.8503
  2295 hud-service write 10 0.2313
  2295 hud-service sendmsg 4 0.0925
  2325 hud-service restart_syscall 1 0.0231
  2329 hud-service restart_syscall 1 0.0231
  2340 hud-service restart_syscall 1 0.0231
 Total 1000000 23125.2435

(gdb) where
#0 0x00007fda8121cfbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007fda7f1bb4b8 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#2 0x00007fda7f1ba3ff in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#3 0x00007fda7f1a49dc in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#4 0x00007fda7f1a5464 in ?? () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#5 0x00007fda82ce9e65 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#6 0x00007fda82d2fc64 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7 0x00007fda82d30582 in QDBusPendingCallWatcher::waitForFinished() () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#8 0x00007fda83eb940b in DBusMenuImporter::slotMenuAboutToShow() () from /usr/lib/x86_64-linux-gnu/libdbusmenu-qt5.so.2
#9 0x00007fda8435d2a6 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x000000000045ab3f in hud::service::DBusMenuCollector::openMenu(QMenu*, unsigned int&) ()
#11 0x000000000045abd8 in hud::service::DBusMenuCollector::openMenu(QMenu*, unsigned int&) ()
#12 0x000000000045abd8 in hud::service::DBusMenuCollector::openMenu(QMenu*, unsigned int&) ()
#13 0x000000000045abd8 in hud::service::DBusMenuCollector::openMenu(QMenu*, unsigned int&) ()
#14 0x000000000045abd8 in hud::service::DBusMenuCollector::openMenu(QMenu*, unsigned int&) ()
#15 0x000000000045abd8 in hud::service::DBusMenuCollector::openMenu(QMenu*, unsigned int&) ()
#16 0x000000000045ae8d in hud::service::DBusMenuCollector::activate() ()
#17 0x0000000000441e43 in hud::service::WindowImpl::activate() ()
#18 0x0000000000439f6a in hud::service::QueryImpl::updateToken(QSharedPointer<hud::service::Window>) ()
#19 0x000000000043a672 in hud::service::QueryImpl::refresh() ()
#20 0x000000000044b115 in ?? ()
#21 0x00007fda8435d2a6 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x000000000045662a in hud::service::ApplicationListImpl::FocusedWindowChanged(unsigned int, QString const&, unsigned int) ()
#23 0x00007fda8435d2a6 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x0000000000467361 in ComCanonicalUnityWindowStackInterface::FocusedWindowChanged(unsigned int, QString const&, unsigned int) ()
#25 0x00000000004678bd in ?? ()
#26 0x0000000000467c63 in ComCanonicalUnityWindowStackInterface::qt_metacall(QMetaObject::Call, int, void**) ()
#27 0x00007fda82cf180f in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#28 0x00007fda8435e22e in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x00007fda823d5c2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#30 0x00007fda823dadf6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#31 0x00007fda84335c2d in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#32 0x00007fda84337e07 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#33 0x00007fda84382cd3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00007fda833dbe04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#35 0x00007fda833dc048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: hud 13.10.1+14.04.20140326-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-20.42-generic 3.13.7
Uname: Linux 3.13.0-20-generic x86_64
ApportVersion: 2.14-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 1 12:23:11 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-03-25 (7 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140323)
SourcePackage: hud
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Colin Ian King (colin-king) wrote :
Pete Woods (pete-woods) wrote :

Hi Colin,

You see in the hud log there's a DBus address listed ":1.92". Can you see which application this is?

Pete Woods (pete-woods) wrote :

Indeed, there's a number of these instances. If I could find out which application it is that causes this, it'd help a lot with debugging.

Colin Ian King (colin-king) wrote :

Hi Pete, how do I look that up?

Colin Ian King (colin-king) wrote :

What I am seeing is the following poll:

poll([{fd=13, events=POLLIN}], 1, 18813) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 18813) = 1 ([{fd=13, revents=POLLIN}])
 poll([{fd=13, events=POLLIN}], 1, 18813) = 1 ([{fd=13, revents=POLLIN}])
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
write(2, "\33[31mvoid DBusMenuImporter::slot"..., 335) = 335
write(2, "\33[31mbool DBusMenuImporterPrivat"..., 300) = 300
write(2, "\33[31mvoid DBusMenuImporter::slot"..., 115) = 115
sendmsg(13, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1 \0\0\0\354\243\2\0r\0\0\0\1\1o\0\33\0\0\0/com/can"..., 136}, {"n\3\0\0\6\0\0\0opened\0\1s\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 32}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 168
sendmsg(13, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\4\0\0\0\355\243\2\0w\0\0\0\1\1o\0\33\0\0\0/com/can"..., 136}, {"\f\2\0\0", 4}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 140
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 25000) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])
poll([{fd=13, events=POLLIN}], 1, 24999) = 1 ([{fd=13, revents=POLLIN}])

.. and this repeats and the timeout drops from 25000 milliseconds down to 1, which is a tad excessive. Polling a gazillion times with sub millisecond timeout is a little bit antisocial ;-)

Pete Woods (pete-woods) wrote :

Yes, this is definitely a bug, I'm not claiming otherwise.

To look up the application I would just use d-feet. Under the session bus, you can look up the connection name, and it will show you the process name at the bottom of the view.

Pete Woods (pete-woods) wrote :
Changed in hud (Ubuntu):
assignee: nobody → Pete Woods (pete-woods)
status: New → In Progress
Pete Woods (pete-woods) wrote :

Obviously those names are temporary. So if you close the window / application they will no-longer exist. Hopefully you can catch one while its still open.

Pete Woods (pete-woods) on 2014-04-02
Changed in hud:
importance: Undecided → Critical
assignee: nobody → Pete Woods (pete-woods)
status: New → In Progress
Pete Woods (pete-woods) on 2014-04-02
Changed in hud:
status: In Progress → Fix Committed
summary: - hud-service is eating up 100% of one of my CPUs in a pool loop
+ hud-service is eating up 100% of one of my CPUs in a poll loop
Alexey Borzenkov (snaury) wrote :

I'm not sure this issue is fixed. I'm running hud_13.10.1+14.04.20140402-0ubuntu1 (based on file ctime being April 7 and me running a kernel built on April 10) and I just got poll loop consuming 100% cpu in hud-service. Unfortunately I didn't debug this very much (my laptop was getting way too hot), and simply restarted hud-service. Logs in hud.log show only ~50 messages like:

Hit DBusMenu safety valve for menu at :1.135 /MenuBar/1

I would expect there would be a flood of these if this code path was hitting in a loop?

Alexey Borzenkov (snaury) wrote :

Installed d-feet and found that :1.135 was kate, if that's important. Given previous screenshot showing gnome-terminal I doubt this is application specific.

Marcia (radio-m) wrote :

I've seen the bug just once, since upgrading to Ubuntu 14.04. I have a 4-core CPU and HUD was consuming 100% of one of the cores; after a while it switched to consuming 100% of a different core. I noticed it because the fan started running quite fast, intermittently. After restarting Ubuntu the issue has not recurred. However when/if it happens, I do consider it critical. A user on a single-core machine would have a tough time debugging the problem with the CPU at 100%. I'm not exactly a Ubuntu geek but if someone wants to instruct me how to capture useful debug info, I could print it out and leave it next to the computer in case it happens again.

Pete Woods (pete-woods) wrote :

This is only going to happen for Qt apps, as they are still using the old DBusMenu protocol to export their menus.

I've tried running Kate and Kontact, as these are the apps I'm hearing that trigger this problem. Opening and closing them, switching around, and generally trying to operate the program hasn't caused it to happen for me yet. :(

If I could only reproduce this somehow, I could fix it!

Pete Woods (pete-woods) on 2014-05-12
Changed in hud:
status: Fix Committed → Confirmed
Marcia (radio-m) wrote :
Download full text (16.7 KiB)

Here's my system log spanning the time when the bug occurred. The log starts around the time when I used System Updater while playing chess, and ends at the place where I rebooted. I don't understand why there were so many thread creations owned by 1000 ... is that the symptom of this bug?

May 13 08:11:25 arpeggio AptDaemon: INFO: CommitPackages() was called: dbus.Array([dbus.String('')], signature=dbus.Signature('s')), dbus.Array([dbus.String('')], signature=dbus.Signature('s')), dbus.Array([dbus.String('')], signature=dbus.Signature('s')), dbus.Array([dbus.String('')], signature=dbus.Signature('s')), dbus.Array([dbus.String('account-plugin-aim'), dbus.String('account-plugin-jabber'), dbus.String('account-plugin-salut'), dbus.String('account-plugin-yahoo'), dbus.String('empathy'), dbus.String('empathy-common'), dbus.String('libfreetype6'), dbus.String('libfreetype6:i386'), dbus.String('liblightdm-gobject-1-0'), dbus.String('libnautilus-extension1a'), dbus.String('lightdm'), dbus.String('linux-firmware'), dbus.String('mcp-account-manager-uoa'), dbus.String('nautilus-data'), dbus.String('nautilus-sendto-empathy'), dbus.String('patch')], signature=dbus.Signature('s')), dbus.Array([dbus.String('')], signature=dbus.Signature('s'))
May 13 08:11:25 arpeggio AptDaemon.Trans: INFO: Queuing transaction /org/debian/apt/transaction/f2d1b68012b5467ca9225b3252b23996
May 13 08:11:25 arpeggio AptDaemon.Worker: INFO: Simulating trans: /org/debian/apt/transaction/f2d1b68012b5467ca9225b3252b23996
May 13 08:11:25 arpeggio AptDaemon.Worker: INFO: Committing packages: dbus.Array([], signature=dbus.Signature('s')), dbus.Array([], signature=dbus.Signature('s')), dbus.Array([], signature=dbus.Signature('s')), dbus.Array([], signature=dbus.Signature('s')), dbus.Array([dbus.String('account-plugin-aim'), dbus.String('account-plugin-jabber'), dbus.String('account-plugin-salut'), dbus.String('account-plugin-yahoo'), dbus.String('empathy'), dbus.String('empathy-common'), dbus.String('libfreetype6'), dbus.String('libfreetype6:i386'), dbus.String('liblightdm-gobject-1-0'), dbus.String('libnautilus-extension1a'), dbus.String('lightdm'), dbus.String('linux-firmware'), dbus.String('mcp-account-manager-uoa'), dbus.String('nautilus-data'), dbus.String('nautilus-sendto-empathy'), dbus.String('patch')], signature=dbus.Signature('s')), dbus.Array([], signature=dbus.Signature('s'))
May 13 08:11:25 arpeggio AptDaemon.Worker: INFO: Processing transaction /org/debian/apt/transaction/f2d1b68012b5467ca9225b3252b23996
May 13 08:12:17 arpeggio rtkit-daemon[1493]: Successfully made thread 5343 of process 4838 (n/a) owned by '1000' RT at priority 2.
May 13 08:12:17 arpeggio rtkit-daemon[1493]: Supervising 7 threads of 3 processes of 1 users.
May 13 08:12:52 arpeggio dbus[483]: [system] Reloaded configuration
May 13 08:12:54 arpeggio NetworkManager[992]: <info> kernel firmware directory '/lib/firmware' changed
May 13 08:12:58 arpeggio AptDaemon.Worker: INFO: Finished transaction /org/debian/apt/transaction/f2d1b68012b5467ca9225b3252b23996
May 13 08:14:15 arpeggio rtkit-daemon[1493]: Successfully made thread 6171 of process 4838 (n/a) owned by '1000' RT at priority 2.
May 13 08:14:15 arpe...

Pete Woods (pete-woods) wrote :

What I'm looking for is a way to cause this to happen by running a single application and performing a particular action in it. Even if it takes a number of tries that's fine. I just need to be able to trigger somewhat reliably within a few minutes.

I know exactly the part of the codebase that is getting sent into this loop, but I simply don't understand how it's getting there.

You can determine which application is the culprit by looking in "~/.cache/upstart/hud.log". In there you'll probably see it mentioning an application hitting a "safety value". The app will have an ID like ":1.22". If you use the application d-feet (see screenshot above) you will be able to figure out which application it is. The IDs are temporary, so if the window has closed, you won't be able to find out what application it was.

Marcia (radio-m) wrote :

Thank you Pete. I will make a note of your instructions and try to get the identity of the application responsible to triggering the loop next time it happens.

At the present time the ~/.cache/upstart/hud.log does not contain the string "safety" ... but you did not expect it would after a reboot.

I will install d-feet. Can I invoke d-feet __after__ the onset of the 100% CPU problem? or does it have to be running all the time to be ready to trap the problem?

Let me just repeat back the instructions as I understand them, to make sure I have it right. When this problem happens again, first search the ~/.cache/upstart/hud.log for the string "safety-valve" and look for an app ID in the form similar to ":1.22". Then invoke d-feet and scan for the matching app ID. When I cursor over the matching app ID, the bottom left corner of the d-feet window should identify the app that triggered the polling loop. Then I will notify you by posting the info here and at that point it is OK to reboot the 100%-CPU system.

James Hunt (jamesodhunt) wrote :

Just hit this again whilst browsing in firefox. The only Qt app I have running (I think) is spotify.

~/.cache/upstart/hud.log shows the offending entry as:

(hud-service:7316): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Hit DBusMenu safety valve for menu at :1.19 /com/canonical/menu/1600078
Hit DBusMenu safety valve for menu at :1.19 /com/canonical/menu/1600078
(ad infinitum)

d-feet shows 1:19 to be upowerd which appears to be doing squat:

$ sudo cat /proc/$(pidof upowerd)/stack
[<ffffffff811cd199>] poll_schedule_timeout+0x49/0x70
[<ffffffff811ce788>] do_sys_poll+0x428/0x540
[<ffffffff811ce975>] SyS_poll+0x65/0x100
[<ffffffff817266bf>] tracesys+0xe1/0xe6
[<ffffffffffffffff>] 0xffffffffffffffff

Pete Woods (pete-woods) wrote :

Unfortunately that's probably the system bus, rather than the session bus you looked at. Sorry for not being clearer.

James Hunt (jamesodhunt) wrote :

Doh! Thankfully, I still have d-feet running and all the apps that were running before I had to kill hud-service. On the session bus, 1:19 is /usr/lib/firefox/firefox - the first object path I see for firefox is: /com/canonical/menu/1600078.

Presumably, we could add some extra details (atleast the pid) to DBusMenuCollector::openMenu() make tracking this issue down easier?

James Hunt (jamesodhunt) wrote :

Hit it again, and again it is triggered by firefox.

Pete Woods (pete-woods) wrote :

Just to check, you guys aren't even invoking HUD, right?

James Hunt (jamesodhunt) wrote :

Correct.

Marcia (radio-m) wrote :

Correct here too. I don't even know what HUD is :-)

James Hunt (jamesodhunt) wrote :

Had 2 further cases of this in the last couple of days. What's interesting though is that I now have a script that monitors for CPU hogs. The script correctly detected hud-service spinning... *but* after a period of time (<1m), it stopped spinning. Attached is the log fwiw.

Greg A (etulfetulf) wrote :

Firefox here too.

Marcia (radio-m) wrote :

Just experienced this bug again. Hadn't seen it since my last report on May 13, 2014. This time I was ready with d-feet. Attached screen capture shows:

(1) CPU number 4 running at 100%

(2) Multiple instances of the string "safety value" in log ~/.cache/upstart/hud.log . The last one is DBus menu item :1.706 and it was hit several times. Also saw it one additional time a bit later in the log, also :1.706. (not shown in screen capture).

(3) d-feet, session bus tab, showing bus name :1.706 = process ID 31925 was started by command line
 /usr/lib/firefox/firefox

Incidentally in the System Monitor, Processes tab, process ID 31925 is indeed Firefox. I had one instance of Firefox running in the background and it was on a web page that I visit frequently without problems (my.yahoo.com). I use the AdBlocker Plus plugin with Firefox. Also saw HUD service in Processes list.

This is my first time using Launchpad so please tell me if I'm doing anything wrong, leaving something out or shouldn't have posted:

The culprit is Firefox in my case too. If I close it, everything returns to normal. HOWEVER, on my machine, this only affects my wife's user account , not my own. If it helps I will provide logs for each of the two users the next time it occurs.

The problem is gone... I haven't changed anything (or been on this PC much since my original posting actually) and according to the changelogs there hasn't been an update in either Firefox or hud since then. No idea what caused this.

Download full text (3.5 KiB)

I had this issue when I had qbittorent running for many days. top shows hud-service eating 99% cpu.
Closing qbittorrent fixed the issue.

The ~/.cache/upstart/hud.log

QDBusError("org.freedesktop.DBus.Error.InvalidArgs", "Unable to find windowId")
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "The name :1.289 was not provided by any .service files"
QCoreApplication::postEvent: Unexpected null receiver
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "The name :1.304 was not provided by any .service files"
QCoreApplication::postEvent: Unexpected null receiver
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
QCoreApplication::postEvent: Unexpected null receiver
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
QCoreApplication::postEvent: Unexpected null receiver
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
QCoreApplication::postEvent: Unexpected null receiver
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
QCoreApplication::postEvent: Unexpected null receiver
void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "No such object path '/MenuBar/1'"
QCor...

Read more...

It's been happening on my laptop since 13.04, and the reason was and still is (on 14.04) opening Nautilus on a Folder that contains either Photos and/or Videos, and once the Thumbnails are shown, then my i7 CPU feels like it's burning, really burning and the fan wants to fly, the hud-service goes crazy consuming both the CPU resources and the memory, which goes up to 1.7GB in no time. Surely it's a memory leak sort of thing.

it is sucking CPU and Memory. I have 32gb of RAM and hud-service was using 85% of it.

I have been having an issue like this for a little over a week now. Oddly coinciding with when one of my ram sticks crapped out it could be that for whatever reason my previous ram total of 4gb was compensating and the problem could be older than i am aware of, in any case it seems the only time it happens for me is when i am running flash applications in chromium. Kill the hud and all comes back to normal.

If i don't catch it early enough then my system becomes virtually unusable so much so that i cant even get up the system monitor to kill the service.

As with others, it seems that as long as i dont have other applications running then i can scrape by with my browsing etc.

14.04LTS (daily updated)
x64
2GB ram

wilk (j-cubizolles) wrote :

I've noticed it when running emacs-snapshot. emacs is very responsive at first but after a while (one hour more or less) it's unbearably slow. Moving the focus from one window to another takes a few seconds. When that happens, both emacs and hud-service cpu usage go up to 100% (I have a dual-core CPU).

Changed in hud (Ubuntu):
importance: Undecided → Critical
James Hunt (jamesodhunt) wrote :

Just got this running hud 14.10+14.10.20140924-0ubuntu1. Just typing in a console and my CPU chewing script popped up a window to alert me to the fact.

muzzol (muzzol) wrote :

I'm affected by this bug too.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

$ uname -a
Linux cprli0792 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg -l | grep hud
ii hud 14.04+14.04.20140604-0ubuntu1 amd64 Backend for the Unity HUD
ii libhud2:amd64 14.04+14.04.20140604-0ubuntu1 amd64 library for exporting items to the Unity HUD

ask me for further info if you need it

Josh Steiner (josh-vitriolix) wrote :

This just hit me this morning. I use a bluetooth keyboard and mouse on my sony vaios s15 laptop. turrning them off did nothing to stop the cpu pegging.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

$ uname -a
Linux stealth 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg -l | grep hud
ii hud 14.04+14.04.20140604-0ubuntu1 amd64 Backend for the Unity HUD
ii libhud2:amd64 14.04+14.04.20140604-0ubuntu1 amd64 library for exporting items to the Unity HUD

Adrian (moshefeit) wrote :

Wow you should "beautify" the log files, i got lost reading on it...

Joshua Holland (joshua-h) wrote :

Just hit this whilst using Gimp (possibly due to a bug in Gimp). Editing an image, Gimp goes unresponsive (window fades), and CPU usage on *all four* cores goes up to 100%. Close Gimp, 3 cores settle down, but hud-service is still 100% on one core, using 1.3GB of RAM and rising. ~/.cache/upstart/hud.log doesn't actually seem to exist at the moment, although hud.log.1.gz etc. do. Therefore I can't do anything useful with d-feet, as I understand it.

here too on 15.04, and i do not know what triggered it.

Gabriel (gabriel-delepine) wrote :

I'm also experiencing this bug. It started when I was using Chromium. Firefox and gimp was close. No torrent

Luís de Sousa (luis-de-sousa) wrote :

I am experiencing this bug with Nemo on Ubuntu 15.04 64 bit. It does not start right away, it may take several hours working with Nemo before the HUD goes crazy.

Even with 4 CPUs and 8 Gb of RAM, the hud-service renders the system unusable once it forces the Swap to kick in.

Reuben Firmin (reubenf) wrote :

Is this still being worked on? This happens to me at least weekly; on my computer, it happens overnight while the computer is idle, and I have to restart X to fix the situation.

ndstate (ndstate) wrote :

This just started happening to me. ETA on a fix please...

muzzol (muzzol) wrote :

several other machines are affected by this bug in our workplace.

not sure if it's worth to mention but one machine NOT displaying this behavior is a 32b system, while the rest are 64b.

affects: hud → ufrs-apt
Robert (robertabcdefgwatson) wrote :

Today I experienced this problem for the first time. The machine that had
the problem has been in operation for many years without this issue.

I want to draw attention to what ouahabix wrote in this thread back on 2014-07-27
as that would appear
to be the same as my experience. My machine is a MythTV recorder with a large
number of video recordings (1365 recordings across two directories). I do not
often use Nautilus on that machine, or use Nautilus in my video directory.

But in the last few days, I had been asked to copy one of the MythTV recordings
for someone and so I wanted to copy a recording to another machine and I
used Nautilus to do that. I did not close Nautilus. About 24 hours later I noticed the machine
was sluggish, and I notice hud-service was using a lot of CPU.

I am running 14.04 and keep the machine up to date with maintenance. I suspect
that ouahabix was on to something way back then. It may not the only cause, but
that observation and my experience are remarkably similar given that I haven't
experienced the problem until I did what ouahabix said would cause the problem.

muzzol (muzzol) wrote :

I'm still hitting this bug in some machines.

Is there any known workaround?

Pete Woods (pete-woods) on 2017-04-10
Changed in ufrs-apt:
assignee: Pete Woods (pete-woods) → nobody
Changed in hud (Ubuntu):
assignee: Pete Woods (pete-woods) → nobody

This is obviously long past the most recent thread activity, but just in case people fall on this page, I had this problem, as well as with evince-thumbnailer.

It turned out to be a permissions problem in my home folder tree. It probably came from some activity I had undertaken while sudoed - my bad, of course.

The solution was simply:

sudo chown -R <my_id>:<my_group_id> /home/<my_id>

Of course, that command may not be fully suitable if you have deliberate ownership differences within your home - adapt as necessary.

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

Other bug subscribers