GNOME-Do uses 200% (two cores) of CPU.

Bug #450852 reported by TDJACR
226
This bug affects 44 people
Affects Status Importance Assigned to Milestone
Do
Fix Released
Medium
Unassigned
X.Org X server
Invalid
Undecided
Unassigned
gnome-do (Ubuntu)
Fix Released
Medium
Unassigned
Nominated for Karmic by TDJACR

Bug Description

Binary package hint: gnome-do

When using GNOME-Do Docky, it'll disappear and begin to utilize full CPU, causing the machine to become sluggish.

This has happened multiple times, on an apparently-random basis.

Revision history for this message
TDJACR (thedjatclubrock) wrote :

This has happened since the Upgrade to Karmic Beta. The dock will also stall for some amount of seconds at arbitrary occurrences, too.

Revision history for this message
Brewster Malevich (brews) wrote :

This happens for me, I don't use docky.

Changed in gnome-do (Ubuntu):
status: New → Confirmed
Robert Dyer (psybers)
Changed in do:
status: New → Incomplete
importance: Undecided → Medium
Revision history for this message
TDJACR (thedjatclubrock) wrote :

I do not have the Microblogging plugin enabled.

TDJACR (thedjatclubrock)
Changed in do:
status: Incomplete → Confirmed
Revision history for this message
Daniel Tiecher (daniel-anderson-tiecher) wrote :

I'm experiencing this issue on Ubuntu 9.04as well as in 9.10 beta. I've noticed that it only happens when if choose to start Do on Gnome's session start. If I open Do after my computer has fully started this bug does not happen.

i really don't know what kind of debugging information you'll need to sort this out but I'll gladly help on doing so. I just need directions of what do I need to do.

Revision history for this message
Robert Dyer (psybers) wrote :

Please dont change our bug status. We do not yet have all the information we need to mark it confirmed. I believe this might be a duplicate bug, but your bug description hints that it isnt.

@dj: does this only happen at startup?

@Daniel: that is another bug, not this bug.

Changed in do:
status: Confirmed → Incomplete
Revision history for this message
TDJACR (thedjatclubrock) wrote : Re: [Bug 450852] Re: GNOME-Do uses 200% (two cores) of CPU.

On Sat, 2009-10-17 at 18:14 +0000, Robert Dyer wrote:
> Please dont change our bug status. We do not yet have all the
> information we need to mark it confirmed. I believe this might be a
> duplicate bug, but your bug description hints that it isnt.
>
> @dj: does this only happen at startup?
>
> @Daniel: that is another bug, not this bug.
>
> ** Changed in: do
> Status: Confirmed => Incomplete
>

I'm sorry, I must have misunderstood proper status procedure. Thanks.

Revision history for this message
TDJACR (thedjatclubrock) wrote :

Sorry about that, I seem to have misunderstood the status system. Won't happen again.

Revision history for this message
Daniel Tiecher (daniel-anderson-tiecher) wrote :

@robert: what bug would it be then because looking through the bug list I could not find anything similar to what I'm experiencing.

Thanks!

Revision history for this message
Robert Dyer (psybers) wrote :

The hottest bug in our list: bug 395190

GNOME do 0.8.2 use 90% CPU when my computer startup

Revision history for this message
Marco Diaz (zethabyte) wrote :

In mi computer with Ubuntu 9.04 64 bits , GnomeDo causes the Xorg process will block.

output in top:

3299 root 20 0 202m 78m 15m R 100 4.5 10:48.43 Xorg

logically, the graphical session will block.

Revision history for this message
Robert Dyer (psybers) wrote :

This does NOT affect Xorg! If 1 process eats all of the cpu then other processes will be starved, there is nothing other processes can do about it!

Changed in xorg-server:
status: New → Invalid
Revision history for this message
Pieter Ennes (skion) wrote :

I have this too, and it indeed happens relatively random with full CPU (and also when I start it manually, so different from #395190). I just noticed this snippet of stdout:

[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[... a lot of the same removed...]
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.138] NameOwnerChanged: org.bansheeproject.CollectionIndexer, '' => ':1.853'
[Debug 20:56:02.237] Running indexer
[Debug 20:56:02.237] Running indexer
[Debug 20:56:02.237] Running indexer
[Error 20:56:21.235] [GDocs] Execution of request failed: http://docs.google.com/feeds/documents/private/full
[Error 20:56:21.237] GMailContacts Error: Execution of request failed: https://www.google.com/m8/feeds/contacts/default/full?max-results=1000

Note the huge amount of Banshee related log entries in the same millisecond. Have now disabled that plug-in and will see if the problem returns.

Revision history for this message
Ken Pratt (kenpratt) wrote :

Just want to add that once the CPU spinning begins I have to kill the process. Then I have to restart it twice; once, kill, then a second time. The it runs again and seems not to have the CPU problem again.

Revision history for this message
mabawsa (mabawsa) wrote :

+1

Anything I can help to debug this as its rather annoying. It also happens on resume from suspend.

Revision history for this message
Mario Vukelic (kreuzsakra) wrote :

I have this too on Karmic 64bit, also if I launch manually, and at random points.

BTW, regarding the remark from comment #1, "the dock will also stall for some amount of seconds at arbitrary occurrences": This seems to be down to the battery docklet. At least it has stopped since I deactivated it. See LP#494898.

Revision history for this message
Harald Glatt (hachre) wrote :

I have the same issue. I did a trace on the mono process running gnome-do and found out that it hangs while trying to read battery info even though I don't have the battery widget thingie enabled...

I was able to reproduce it 100% by following these steps:
- start gnome-do with docky and without the battery widget
- start to trace the process in some terminal window
- set up icon zoom to 140% of original size
- have around 10 items in docky total
- very fast hover the mouse from the very left to the very right item back and forth

Results:
- within 5 seconds dockys icon zoom freezes for several seconds
- trace shows reading battery info...
- after a few seconds normal operation continues

This also happens if you don't try to trigger it of course, just a lot less often than it does when you do this trick.

Revision history for this message
karlrt (karlrt) wrote :

try out the ppa: (gnome-do 8.3.1) https://launchpad.net/~do-core/+archive/ppa

i believe this bug is a duplicate of https://bugs.launchpad.net/do/+bug/395190, if the ppa fixes your problems it shurely is

Revision history for this message
Mario Abarca (knkillname) wrote :

I also have the same issue, but I am not using Docky.

All I needed to do is install Gnome-do on a fresh Karmik, make it runnable at startup and reboot two times (the first time it will work ok).

I confirm what Daniel Tiecher said: "If I open Do after my computer has fully started this bug does not happen."

Revision history for this message
Vanishing (vanishing) wrote :

opps...sry about the status change..

Changed in do:
status: Incomplete → Confirmed
status: Confirmed → Incomplete
Revision history for this message
Jouke (digigram) wrote :

ppa version fixes this for me. Thanks

Revision history for this message
Hew (hew) wrote :

Same problem, 400% CPU on quad core with gnome-do 0.8.3.1+dfsg-1 on Lucid. I cannot work out what is triggering the issue; sometimes a command causes it, but usually it's fine.

Changed in gnome-do (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Alexandre Provencio (alexandreprovencio) wrote :

gnome-do 0.8.3.1+dfsg-1 on Lucid, when resuming from suspend

Revision history for this message
Johannes Mockenhaupt (mockenh-deactivatedaccount) wrote :

I see this bug and it appears minutes or hours after activating the banshee plugin. Not having the plugin enabled I don't see the problem, so in my case it's definately the banshee plugin. (on x64 lucid, but I had the same problem on x86 karmic with ubuntu-provided versions).

Revision history for this message
Chris Halse Rogers (raof) wrote :

I'm fairly sure that this has been fixed in trunk. I want to land some more merge requests, fix a couple more bugs, and then do a new release.

Changed in do:
status: Incomplete → Fix Committed
Revision history for this message
a (rtyjfgsef45yrf-deactivatedaccount) wrote :

I will just add that I rarely experience this bug except for when I logout and then log back in (not restart), if I do that it almost always starts happening (using 0.8.3.1 on Lucid).

Revision history for this message
Ben VB (benvb) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :

Same here on maverick, 64bit. After resuming from suspend, gnome-do takes up nearly 800% CPU-Time on my core i7.

After "killall gnome-do" and restarting gnome-do, everything is back to normal ...

Revision history for this message
Christoph Buchner (bilderbuchi) wrote :

same here (only on resume).
Chris, any chance to get at least a PPA release soon? There are other fixed bugs waiting for a long time for a release, too (e.g. bug #531568)...

Revision history for this message
Scott Pledger (spledger) wrote :

I have this issue as well - 32 bit Maverick. Freezes on resume from suspend, going to 200% CPU usage on my Core 2.

Revision history for this message
leeight (leeight) wrote :

I have the same issue as well, 32 bit Maverick & 0.8.3.1+dfsg-2ubuntu1

Revision history for this message
Alkalyzer (alkalyzer) wrote :

The same trouble here under Maverick (was also the case when I was running Lucid) with Gnome-Do 0.8.3.1.
Everything runs smoothly, then after a while (could be either minutes or hours, it depends), Gnome-Do reaches and holds 100% cpu and has to be killed.

Revision history for this message
Christof Buchbender (ascurion) wrote :

I can only confirm what has been said in the last comment. I find exactly the same behavior with Gnome-Do 0.8.3.1 in Ubuntu 10.10.

Revision history for this message
Chris Halse Rogers (raof) wrote :

This should be fixed in 0.8.4.

I'll do a little cleaning up in do-plugins, cut another do-plugins release, and then update the Debian & Ubuntu packages.

Changed in do:
status: Fix Committed → Fix Released
Revision history for this message
Ricardo Sansores Aguilar (rsansores) wrote :

I can confirm the issue. Ubuntu 10.10 x64. I detected the problem because my cpu starts to overheat and gnome-do is ussing 700% in system monitor funny....

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

This bug was fixed in the package gnome-do - 0.8.4-0ubuntu1

---------------
gnome-do (0.8.4-0ubuntu1) natty; urgency=low

  * The Race Against FF upload. Merge from unreleased Debian git.
    Remaining Ubuntu changes:
    + debian/patches/05_disable_resize_grips.patch.diff:
      Disable resize handles for the Do windows.
    + debian/control:
      Bump gtk# build dep for HasResizeGrip API.
  * New Debian changes:
  * The long fortold release
    + Fixes a threadsafety issue resulting in 100% CPU usage (Closes: 565591,
      LP: #450852).
    + Proxies all keyring calls to the GTK main thread, as required by the new
      gnome-keyring (Closes: 603876, LP: #553643)
  * debian/patches/00_bundledlibs.dpatch:
  * debian/rules:
    + Upstream has dropped bundled gmcs binary; now 100% DFSG-free, so we don't
      have to repack the tarball or patch the buildsystem.
  * debian/patches/03_disable_docky.dpatch:
    + Drop. Docky is now gone in the upstream tarball.
  * debian/rules:
  * debian/control:
  * debian/patches/*:
    + Switch to quilt to harmonise with other pkg-cli-* packages.
  * debian/control:
    + Drop recommends on gnome-do-docklets. Docky is now a separate package,
      so the docklets are useless for Do.
    + Bump Breaks on gnome-do-plugins to 0.8.3. Do no longer provides the Wink
      library, which has been imported into the 0.8.3 do-plugins sources.
    + Bump standards-version; no changes needed.
    + Migrate to git and update VCS fields appropriately
 -- Christopher James Halse Rogers <email address hidden> Tue, 15 Feb 2011 21:50:02 +1100

Changed in gnome-do (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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