Do

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

Bug #450852 reported by TDJACR on 2009-10-13
226
This bug affects 44 people
Affects Status Importance Assigned to Milestone
Do
Medium
Unassigned
X.Org X server
Invalid
Undecided
Unassigned
gnome-do (Ubuntu)
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.

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.

Brewster Malevich (brews) wrote :

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

Changed in gnome-do (Ubuntu):
status: New → Confirmed
Robert Dyer (psybers) on 2009-10-16
Changed in do:
status: New → Incomplete
importance: Undecided → Medium
TDJACR (thedjatclubrock) wrote :

I do not have the Microblogging plugin enabled.

TDJACR (thedjatclubrock) on 2009-10-17
Changed in do:
status: Incomplete → Confirmed

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.

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

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.

TDJACR (thedjatclubrock) wrote :

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

@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!

Robert Dyer (psybers) wrote :

The hottest bug in our list: bug 395190

GNOME do 0.8.2 use 90% CPU when my computer startup

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.

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
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.

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.

mabawsa (mabawsa) wrote :

+1

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

Mario Vukelic (mario-vukelic) 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.

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.

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

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."

Vanishing (vanishing) wrote :

opps...sry about the status change..

Changed in do:
status: Incomplete → Confirmed
status: Confirmed → Incomplete
Jouke (digigram) wrote :

ppa version fixes this for me. Thanks

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

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

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

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

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

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 ...

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

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.

leeight (leeight) wrote :

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

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.

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.

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

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....

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

Duplicates of this bug

Other bug subscribers