GNOME do 0.8.2 use 90% CPU when my computer startup。

[Garbin Huang]

Originally reported with:
Ubuntu 8.10, GNOME Do:0.8.2 install from sourcecode

Since reported with various Ubuntu and Gnome Do versions.

[Robert Dyer (psybers)]

Does the CPU spike occur only during startup?

[Garbin Huang (garbinhuang)]

Yes! I killed GNOME Do that use 90% CPU then restart it, the problem is gone

[litros (litros)]

I'd like to report the same problem, after I updated GNOME do to version 0.8.2 sometimes after startup it uses 100% of my CPU.
The only way to shut it down is to go to system monitor and kill the process.

[Jonathan Lumb (jonolumb)]

This bug is affecting me too. I'm running Gnome Do 0.8.2 on Ubuntu 9.04 and didn't have this problem on 0.8.1.

The CPU spike only occurs when the computer starts up - after which my laptop rockets up to a whopping 83°C and uses almost 100％ CPU if I don't kill the process in time. After killing Gnome Do and opening it again, it starts up fine with no CPU spike.

This is a serious bug and needs fixing promptly - is there any more info I can provide that would be useful?

[Robert Dyer (psybers)]

Does this only occur if Do automatically starts up? Try disabling automatic startup and manually run it. IE, does this happen only on the first run or literally if only ran as a startup application.

*IF* it is only happening during startup, then at least you have a temporary workaround to disable automatic startup and just manually run it. We will be fixing the bug asap, but at least you could work around.

[Robert Dyer (psybers)]

Can someone please run with --debug and get us a log?

[Chris Halse Rogers (raof)]

Can we get a log from someone? If it's only on startup, then ~/.xsession-errors should contain some GNOME Do logs. Can you edit the ~/.config/autostart/gnome-do.desktop file, and replace the
Exec=gnome-do
line with
Exec=gnome-do --debug
then start up, reproduce this bug, run "killall -SIGQUIT gnome-do", and then attach your ~/.xsession-errors file to this bug?

[Robert Dyer (psybers)]

@cgk and Jonathan: are you both using the Microblogging plugin? Does disabling that plugin fix the problem?

[Garbin Huang (garbinhuang)]

I don't know why that I can't reproduce this bug after I disable the microblogging plugin, even if I enable the plugin again.

My plugin list is "files and folders", microblogging, pidgin. that's all.

Hope someone can reproduce it.

[Alex Launi (alexlauni)]

How much are you indexing with files and folders?

On Mon, Jul 6, 2009 at 7:21 AM, Garbin Huang <email address hidden> wrote:

> My plugin list is "files and folders", microblogging, pidgin. that's
> all.
>

--
--Alex Launi

[litros (litros)]

I don't use the microblogging plugin, i only use the plugins: files and folder, firefox, nothing else.
The thing is, that this problem doesn't occur only every startup sometimes works fine sometimes uses 100%, it can also happens after an hour of usage.
As selected theme I have Docky, and yes I have Gnome Do on automatic startup. I have an Intel graphic card I don't know if this is a problem, but with Gnome Do 0.8.1 I hadn't any problems at all, and I used more plugins.

[Garbin Huang (garbinhuang)]

just my home directory with depth 2 and a folder with depth 1, Not more than 50 files and folders.
with gnome do 0.8.1 hadn't any problems, even if indexing files and folders more than 5000, Just get a notice from GNOME Do.

[Jonathan Lumb (jonolumb)]

interesting - i too disabled the microblogging plugin and re-enabled it... and now I can't seem to reproduce the bug either!?

[nexus (bugie)]

I don't use the microblogging plugin and this bug is still there.

[delaossa (adelaossa)]

Hello,
I am also experimenting the same issue (on Ubuntu 9.04):
- gnome-do 0.8.2 uses 90% CPU immediately after startup.
- The problem goes killing the process and re-launching the application.
- gnome-do 0.8.1 was working perfectly fine.
- I am not using any plugin.

I have just tried to do what Chris Halse Rogers wrote on 2009-07-06
in order to provide some log, but due to the apparently random behavior of the problem,
gnome-do has started good this time.
As soon as it fails again I'll try to give some feedback to you.

[delaossa (adelaossa)]

Ok..
gnome-do has just crashed again.
I changed ~/.config/autostart/gnome-do.desktop to have the --debug option.
however "killall -SIGQUIT gnome-do" didn't kill anything.
One has to kill this process:
delaossa 3814 171 0.7 284996 29928 ? Sl 15:43 4:20 /usr/bin/cli /usr/lib/gnome-do/Do.exe
My ~/.xsession-errors file after that is the following:

[Mocto (moctoo)]

Same bug here :
-happens once in a while, sometimes starts just fine
-happens only on system startup
-appeared with 0.8.2, no problem with 0.8.1
-microblogging plugin disabled and never used
I'll send logs as soon as possible.

[Garbin Huang (garbinhuang)]

I reproduce it, this's my xsession-errors, It looks like gnome do enter the infinite loop.

[Thiago Teixeira (tvst)]

Just a "me too". It only happens on startup, and only on some startups. Pretty much exactly what Mocto said, above. And, strangely, whenever it doesn't happen, the "home" icon on my docky doesn't work (that is, it doesn't launch Nautilus at all).

I logged it a few times when the bug happened, but there was nothing strange in the logs. Even so, I can try to grab the logs again if you are interested.

[Thiago Teixeira (tvst)]

By the way, why is this marked as "Medium" importance. This should be "Critical" as it stops people who aren't power-users from using Gnome-Do. (People who don't know how to kill apps)

[Chris Halse Rogers (raof)]

The thread stacktrace shows 3 separate threads trying to update the universe, all of which are in MaybeCreateFromDesktopFile. That might narrow down the search somewhat.

[Chris Halse Rogers (raof)]

It would be useful for other people who experience this problem to post thread stacktraces, so we can confirm similar behaviour.

Again, for those who didn't notice the first time: to do this, you should log in, confirm that Do is exhibiting this behaviour, then issue the command: "killall -SIGQUIT gnome-do" in a terminal. This will drop a stacktrace into ~/.xsession-errors, which you should attach here.

Don't do this after you've been logged in for a long time; the xsession-errors logfile will only grow to a certain size, then ignore everything else. If it's already too big, the stacktrace won't be included.

[Thiago Teixeira (tvst)]

Here's my xsession-errors. I don't think there's anything relevant other than this line:

(Do:3695): Wnck-CRITICAL **: wnck_set_client_type got called multiple times.

[Alex Launi (alexlauni)]

We dont need just xsession-errors, you need to kill Do with the command
chris posted, and then give us the xsession-errors with the full thread
trace.

--
--Alex Launi

[Thiago Teixeira (tvst)]

Just to be clear, this is what I did:
1) Started the computer, noticed Gnome Do immediately taking up ~100% of one of my cores.
2) pkill -9 gnome-do
3) cp .xsession-errors xsession-errors
4) Posted xsession-errors on Launchpad

So the problem is that I used "-9" (SIGKILL) instead of SIGQUIT?

[Alex Launi (alexlauni)]

Yes. Please do *exactly* what Chris said. We give specific instructions for
a reason.

--
-- Alex Launi

[chrisinspace (chrishansford99)]

Followed Chris' instructions. See attached file.

[Thiago Teixeira (tvst)]

@Alex: I'm attaching new logs. This time I used SIGQUIT, but Gnome-Do just wouldn't quit. So, after trying twice again I gave up and did a SIGKILL.

And this is without "--debug". I couldn't get it to crash with "--debug". But even without "--debug" the dump file is full of Gnome-Do logs, and many threads updating the universe in MaybeCreateDesktopItem.

[Chris S. (cszikszoy)]

tvst, of course it won't quit -- that's by design. Sending sigquit to
a mono process only dumps a stacktrace for each of the associated
threads. The goal here is not to force Do to exit, just to get a
detailed stacktrace.

On Tue, Aug 4, 2009 at 11:36 AM, tvst<email address hidden> wrote:
> @Alex: I'm attaching new logs. This time I used SIGQUIT, but Gnome-Do
> just wouldn't quit. So, after trying twice again I gave up and did a
> SIGKILL.
>
> And this is without "--debug". I couldn't get it to crash with "--
> debug". But even without "--debug" the dump file is full of Gnome-Do
> logs, and many threads updating the universe in MaybeCreateDesktopItem.
>
> ** Attachment added: "xsession-errors"
>   http://launchpadlibrarian.net/29903860/xsession-errors
>
> ** Attachment removed: "xsession-errors"
>   http://launchpadlibrarian.net/29834476/xsession-errors
>
> --
> GNOME do 0.8.2 use 90% CPU when my computer startup。
> https://bugs.launchpad.net/bugs/395190
> You received this bug notification because you are a member of GNOME Do
> Core Team, which is subscribed to GNOME Do.
>

[Thiago Teixeira (tvst)]

Understood. Thanks for the explanation.

[Martin Vielsmaier (martin-vielsmaier)]

I also have this problem. Do runs and comes up when I press the shortcut, but seems not to have anything in it's index and no plugins loaded. (I can type whatever I want, it always shows the "copy to clipboard" action.)

[Chris S. (cszikszoy)]

Martin, this probably isn't related. Depending on which plugins (and
how many) you have loaded, it can take a few moments for Do to
initialize it's universe of items. If you have many plugins enabled
it is typical to have a bit of a delay before those items become
available. Now if you are experiencing excessively long startups, or
excessive memory usage at startup, then that may be a bug.

On Tue, Aug 4, 2009 at 2:56 PM, Martin
Vielsmaier<email address hidden> wrote:
> I also have this problem. Do runs and comes up when I press the
> shortcut, but seems not to have anything in it's index and no plugins
> loaded. (I can type whatever I want, it always shows the "copy to
> clipboard" action.)
>
> ** Attachment added: ".xsession-errors"
>   http://launchpadlibrarian.net/29909049/.xsession-errors
>
> --
> GNOME do 0.8.2 use 90% CPU when my computer startup。
> https://bugs.launchpad.net/bugs/395190
> You received this bug notification because you are a member of GNOME Do
> Core Team, which is subscribed to GNOME Do.
>

[Martin Vielsmaier (martin-vielsmaier)]

Forgot to mention that it uses my processors nearly 100%. The situation does not change for about 30 minutes (that was the longest I waited before killing Do) except for my notebook getting really hot. I did not see any excessive memory usage though.

[neclepsio (neclepsio)]

Same problem.
I can add it lasts way more than 30 minutes, because once I didn't notice it and it lasted all night long.

Full thread dump:

"" tid=0x0x2296e0 this=0x0x25dd0:
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0x00004>
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff>
  at Gtk.Application.Run () <0x00007>
  at Do.Do.Main (string[]) <0x001f1>
  at (wrapper runtime-invoke) Do.Do.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff>

"" tid=0x0x1647b90 this=0x0x45e2b60:
  at System.Collections.Generic.Dictionary`2.ContainsKey (object) <0x000b8>
  at Do.Universe.Linux.ApplicationItem.MaybeCreateFromDesktopItem (string) <0x00046>
  at Do.Universe.Linux.ApplicationItemSource.<LoadDesktopFiles>m__14 (string) <0x0000d>
  at <CreateSelectIterator>c__Iterator16`2.MoveNext () <0x0009c>
  at <CreateWhereIterator>c__Iterator29`1.MoveNext () <0x000ea>
  at <CreateWhereIterator>c__Iterator29`1.MoveNext () <0x000ea>
  at <CreateSelectManyIterator>c__Iterator18`2.MoveNext () <0x00123>
  at <CreateCastIterator>c__Iterator0`1.MoveNext () <0x000d8>
  at <CreateConcatIterator>c__Iterator1`1.MoveNext () <0x000bb>
  at <CreateDistinctIterator>c__Iterator3`1.MoveNext () <0x00129>
  at System.Collections.Generic.List`1.AddEnumerable (System.Collections.Generic.IEnumerable`1) <0x00062>
  at System.Collections.Generic.List`1..ctor (System.Collections.Generic.IEnumerable`1) <0x00063>
  at System.Linq.Enumerable.ToArray (System.Collections.Generic.IEnumerable`1) <0x000ed>
  at Do.Universe.Linux.ApplicationItemSource.UpdateItems () <0x0009e>
  at Do.Universe.Safe.SafeItemSource.UpdateItems () <0x0001b>
  at Do.Core.UniverseManager.ReloadSource (Do.Universe.ItemSource,System.Collections.Generic.Dictionary`2) <0x0008d>
  at <ReloadUniverse>c__AnonStorey24.<>m__33 (Do.Universe.ItemSource) <0x00016>
  at System.Linq.EnumerableExtensions.ForEach (System.Collections.Generic.IEnumerable`1,System.Action`1) <0x00055>
  at Do.Core.UniverseManager.ReloadUniverse () <0x0009b>
  at Do.Core.UniverseManager.InitializeAsync () <0x0000e>
  at <RunOnThread>c__AnonStorey27.<>m__39 () <0x00016>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0xffffffff>

"" tid=0x0x29f6b90 this=0x0x45e2a80:
  at System.Collections.Generic.Dictionary`2.ContainsKey (object) <0x000b8>
  at Do.Universe.Linux.ApplicationItem.MaybeCreateFromDesktopItem (string) <0x00046>
  at Do.Universe.Linux.ApplicationItemSource.<LoadDesktopFiles>m__14 (string) <0x0000d>
  at <CreateSelectIterator>c__Iterator16`2.MoveNext () <0x0009c>
  at <CreateWhereIterator>c__Iterator29`1.MoveNext () <0x000ea>
  at <CreateWhereIterator>c__Iterator29`1.MoveNext () <0x000ea>
  at <CreateSelectManyIterator>c__Iterator18`2.MoveNext () <0x00123>
  at <CreateCastIterator>c__Iterator0`1.MoveNext () <0x000d8>
  at <CreateConcatIterator>c__Iterator1`1.MoveNext () <0x000bb>
  at <CreateDistinctIterator>c__Iterator3`1.MoveNext () <0x00129>
  at System.Collections.Generic.List`1.AddEnumerable (System.Collections.Generic.IEnumerable`1) <0x00062>
  at System.Collections.Generic.List`1..ctor (System.Collections.Generic.IEnumerable`1...

[Chris Halse Rogers (raof)]

 status triaged

Yup. Certainly looks like some madness in the ApplicationItemSource.
Thanks for the confirmation, everyone.

[Rami Al-Rfou' (rmyeid)]

This is another xsession errors file, I downgraded to 0.8.1 when I was jaunty, now I just figured out that I was upgraded to 0.8.2 in Karmic, I don't think this is a wise idea while this bug is still open !

[Jonathan Lumb (jonolumb)]

This is a potentially devastating bug for notebook users - I just checked my laptop temperature when the CPU was stuck on 100% due to Gnome-Do and after just three or four minutes after startup, the temperature was heading above 80°C (176°F) which could potentially cause serious heat damage to the laptop. If a user started up their notebook and then left it unattended and the bug occurred, they could completely ruin their machine. This bug needs fixing - and soon too!

[Eric Morgan (gemorgan)]

Same for me as #37 above. CPU stuck at 100% and that core's temp went to 82°C with fan running on full. It's disturbing that Do could do this but even more disturbing that there is even a CPU load that the Lenovo T61 cooling solution couldn't handle. This simply should never happen.

[Rami Al-Rfou' (rmyeid)]

I solved the problem by deleting the ~/.gconf
of course I did not delete the folder, I just renamed it.
mv ~/.gconf ~/.gconf.old
Gnome will create a new gconf folder which means that you will loose some
settings.
to restore the old gconf
cp ~/.gconf.old ~/.gconf

after this trick I did not face the problem again.

On Fri, Aug 21, 2009 at 22:00, nowhere <email address hidden> wrote:

> Same for me as #37 above. CPU stuck at 100% and that core's temp went to
> 82°C with fan running on full. It's disturbing that Do could do this but
> even more disturbing that there is even a CPU load that the Lenovo T61
> cooling solution couldn't handle. This simply should never happen.
>
> --
> GNOME do 0.8.2 use 90% CPU when my computer startup。
> https://bugs.launchpad.net/bugs/395190
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Rami Eid

[Robert Dyer (psybers)]

You shouldnt need to delete ~/.gconf, at best you should delete: ~/.gconf/apps/gnome-do

[Félix Velasco (felix-velasco)]

The bug seems like a race condition, when a reload begins before the original loading finishes. Given this happens since 0.8.2, I'd bet that the NetworkManager-based reload, that is new in 0.8.2, is the key.

Please, test the patch I posted in comment #110 and check whether the problem continues.

[Alex Launi (alexlauni)]

Ok, I just commited felix's patch to trunk after testing it for a few days and not seeing any spikes. Could everyone please test lp:do and let us know if there is any weirdness?

[Ryan Cragun (ryan-rightscale)]

Trying to use the trunk build, but I can't get it to configure.

"
config.status: creating Do.Platform.OSX/AssemblyInfo.cs
config.status: creating Do.Platform.Windows/AssemblyInfo.cs
config.status: creating Do.Universe/Makefile
config.status: creating Do.Universe/src/AssemblyInfo.cs
config.status: error: cannot find input file: `libdo/Makefile.in'
"
On Thu, 2009-11-19 at 20:56 +0000, Alex Launi wrote:
> Ok, I just commited felix's patch to trunk after testing it for a few
> days and not seeing any spikes. Could everyone please test lp:do and let
> us know if there is any weirdness?
>
> ** Changed in: do
> Status: In Progress => Fix Committed
>
> ** Changed in: do
> Assignee: (unassigned) => Alex Launi (alexlauni)
>

[Alex Launi (alexlauni)]

install libgconf2-dev

--
--Alex Launi

[Saarmstrong (saarmstrong)]

The fix mentioned by James was recent merged into gnome-do trunk:

http://bazaar.launchpad.net/~do-core/do/trunk/revision/1315

I have not tested it, but if it works for James and all the Ubuntu users on the upstream bug, we should apply it.

[Ryan Cragun (ryan-rightscale)]

Thanks. Guess I missed a dependency, it's working like a charm now.

[Jonathan Lumb (jonolumb)]

Great... looks like some progress is finally being made on this long-standing issue. Thanks to everyone for their hard work, it really is appreciated!

[Aaron (armahillo)]

the person that mentioned the interaction with the music player got me thinking -- Rhythmbox quit working for me as well after a recent update. I know that I had integrated Gnome Do with Rhythmbox -- could this be a possible cause?

[Duncan Lithgow (duncan-lithgow)]

I have reported bug 486434 and marked it as a duplicate of this. It includes the Dependencies.txt and XsessionErrors.txt files. I grabbed these with '$ ubuntu-bug gnome-do' shortly after killing Gnome Do and restarting it. Because none of the following is listed in the attached files, here is a list of plugins enabled: (Official) Firefox v3.0, GNOME Dictionary v1.0, GNOME Screenshot v1.0, GNOME Session Management v1.7, GNOME Terminal, Google Calculator v1.0, Launchpad v1.1 OpenSearch Web Search v1.2, Pastebin v1.1, TinyUrl v1.0, Tomboy v1.4, Window Manager v1.2. (Community Plugins) Dropbox v1.0, Flickr v1.4, Google Maps v1.1, Skype v1.2, Tracker Search v1.0, Translate v1.1 (Docklets) Battery Docklet v1.0, CPU Monitor Docklet v1.0, Switcher Docklet v1.0, Weather Docklet v1.0. 'Start GNOME Do at login = yes'. (Sorry if I'm re-stating the obvious, I haven't read all 120+ comments)

[Jbottomley (jbottomley)]

(In reply to comment #10)
> http://launchpadlibrarian.net/35748706/395190.patch
>
> I've spliced this into the 11.2 package and have installed it on my system.
> Will report back in a week or so whether it seems to have fixed the problem or
> not

OK, it's been running in my setup for 7 days now without once exhibiting the problem. The patch certainly seems to mitigate the problem.

[ju (clemenzi-santo-gmail)]

I have the same bug on Karmic Koala. At every boot gnome-do (0.8.2) use the cpu (both cores) 100%.

It works normal after killing and restarting the application.

Sometimes the same thing happens on rhythmbox (100% cpu) after i start it, I have the rhythmbox plugin enabled in do, but I can't say if the two things are related.

[Thiago Teixeira (tvst)]

Alex: I have applied the patch and things seem to be running smoothly now. My only concern is that on the first boot immediately after I applied the patch I experienced a buggy behavior which I hadn't seen before:

On my first boot, Do did not load at all and locked me from using the desktop (no respose from keyboard or mouse). Ctrl+Alt+F1 worked, though, and I manually killed Do from there. The desktop worked fine after that.

Since that one time, I haven't had a single crash in Do after many reboots.

[Eric Morgan (gemorgan)]

I have experienced the same lockup without installing the patch with the
same Ctrl+Alt+F1 kill Do solution...

On Tue, Nov 24, 2009 at 1:19 AM, tvst <email address hidden> wrote:

> Alex: I have applied the patch and things seem to be running smoothly
> now. My only concern is that on the first boot immediately after I
> applied the patch I experienced a buggy behavior which I hadn't seen
> before:
>
> On my first boot, Do did not load at all and locked me from using the
> desktop (no respose from keyboard or mouse). Ctrl+Alt+F1 worked, though,
> and I manually killed Do from there. The desktop worked fine after that.
>
> Since that one time, I haven't had a single crash in Do after many
> reboots.
>
> --
> GNOME do 0.8.2 use 90% CPU when my computer startup。
> https://bugs.launchpad.net/bugs/395190
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[C.J. Collier (cjcollier)]

I'm seeing a similar problem with v0.8.2+dfsg-1 (karmic). It only happens on resume from suspend, though, so it may be LP bug #226816

[Dominique Leuenberger aka DimStar (dimstar)]

gnome-do 0.8.3 has just been submitted to GNOME:Factory. The update is purely of bug fix nature and explicitly mentions this very bug as being fixed.

suggest to publish gnome-do 0.8.3 as an update for 11.2

[Captain-magnus-opensuse (captain-magnus-opensuse)]

As per comment#13, +1 since it is a bug fix only release

[Meissner-novell (meissner-novell)]

"just a bugfix release" should not be a standalone acceptance criterium.

"real users affected by an issue ... and can be solved by a bugfix release update" is a better criteria.

otherwise we could just publish every bugfix release (which would be overkill).

for gnome-do I would also say: Yes, update. +1

[Cdengler (cdengler)]

+1

update process started

[Swamp-suse (swamp-suse)]

The SWAMPID for this issue is 29445.
Please submit the patch and patchinfo file using this ID.
(https://swamp.suse.de/webswamp/wf/29445)

[Mark Cariaga (mzc)]

Bug is still not fixed...still hangs on start-up occasionally

On Thu, 2009-12-10 at 02:15 +0000, Chris Halse Rogers wrote:
> ** Changed in: do
> Milestone: 0.9 => 0.8.3
>
> ** Changed in: do
> Status: Fix Committed => Fix Released
>

[Jeroen (c0p3rn1c)]

It makes Ubuntu less stable becaue of the high cpu usage. I'm affraid people will not notice this and blame karmic.

[Robert Dyer (psybers)]

@Jeroen: Upgrade to 0.8.3.1, this has been fixed.

[Fausto Piovesan (faustop)]

Changed the bug to confirmed in Ubuntu as it still occurs on a fully updated install. People are reporting this bug as fixed on version 0.8.3.1 of gnome-do, but this version is not yet available on Ubuntu.

[Mark Cariaga (mzc)]

@fausto
You have to add the ppa to update to current gnome do release. Search
gnome do in launchpad

Sent from my iPhone

On Dec 16, 2009, at 7:16 AM, Fausto Piovesan <email address hidden> wrote:

> Changed the bug to confirmed in Ubuntu as it still occurs on a fully
> updated install. People are reporting this bug as fixed on version
> 0.8.3.1 of gnome-do, but this version is not yet available on Ubuntu.
>
> --
> GNOME do 0.8.2 use 90% CPU when my computer startup。
> https://bugs.launchpad.net/bugs/395190
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in GNOME Do: Fix Released
> Status in X.Org X server: Invalid
> Status in Ubuntu: Confirmed
>
> Bug description:
> Originally reported with:
> Ubuntu 8.10, GNOME Do:0.8.2 install from sourcecode
>
> Since reported with various Ubuntu and Gnome Do versions.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/do/+bug/395190/+subscribe

[Andrew Gunnerson (cxl)]

Here's a working TEMPORARY SOLUTION. Since Gnome-Do doesn't work when launched by the Gnome session manager, I made Gnome call up a script which launches Gnome-Do.

I made a script in ~/Run_Gnome_Do with:

#!/bin/sh
./usr/bin/gnome-do

and ran "sudo chmod a+x ~/Scripts/Run_Gnome_Do" and had Gnome run that.

[Wolter HV (wolterh)]

Hm.. GNOME Do did work for me perfectly (0.8.3.x version), but when I updated my kernel to version 2.6.32.x, a new problem surged.

Now gnome-do starts and doesn't eat all cpu, but it doesn't show up.

[Mark Cariaga (mzc)]

@Wolter
It's not the kernel upgrade you did that may be causing this. I'm using
the default kernel, 2.6.31-16, I also experience the same bug. But this
only happens occasionally, I have unchecked all plugins, which i think
help reduced occurrence.

On Thu, 2009-12-17 at 07:07 +0000, Wolter Hellmund wrote:
> Hm.. GNOME Do did work for me perfectly (0.8.3.x version), but when I
> updated my kernel to version 2.6.32.x, a new problem surged.
>
> Now gnome-do starts and doesn't eat all cpu, but it doesn't show up.
>

[kajdo (kajdo0815)]

Hi,

looks like the people are happy with the fix, unfortunately i'm not since the package for jaunty seems to be broken https://launchpad.net/~do-core/+archive/ppa/+build/1388675.

I added the -testers deb to my source list and added the key to install it via apt-get update/install but apt tells me i have already installed the newest version (0.8.2).

could anyone please help me.

btw. it seems that gnome-do is just consuming that much cpu when it starts up directly after login - when i wait a bit and start it in gnome via alt+f2 and 'gnome-do' everything works fine.

any comment to my problem appreciated

thx,
kajdo

[dafero (daferoes)]

Hi kajdo, the newest version is the 0.8.3.1
That version is working fine, al least in my own case. I am using Ubuntu
Karmic.

Check it out!

2009/12/31 kajdo <email address hidden>

> Hi,
>
> looks like the people are happy with the fix, unfortunately i'm not
> since the package for jaunty seems to be broken https://launchpad.net
> /~do-core/+archive/ppa/+build/1388675.
>
> I added the -testers deb to my source list and added the key to install
> it via apt-get update/install but apt tells me i have already installed
> the newest version (0.8.2).
>
> could anyone please help me.
>
> btw. it seems that gnome-do is just consuming that much cpu when it
> starts up directly after login - when i wait a bit and start it in gnome
> via alt+f2 and 'gnome-do' everything works fine.
>
> any comment to my problem appreciated
>
> thx,
> kajdo
>
> --
> GNOME do 0.8.2 use 90% CPU when my computer startup。
> https://bugs.launchpad.net/bugs/395190
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in GNOME Do: Fix Released
> Status in X.Org X server: Invalid
> Status in “gnome-do” package in Ubuntu: Confirmed
>
> Bug description:
> Originally reported with:
> Ubuntu 8.10, GNOME Do:0.8.2 install from sourcecode
>
> Since reported with various Ubuntu and Gnome Do versions.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/do/+bug/395190/+subscribe
>

[Swamp-a (swamp-a)]

Update released for: gnome-do, gnome-do-debuginfo, gnome-do-debugsource, gnome-do-lang
Products:
openSUSE 11.2 (debug, i586, x86_64)

[Vincent Untz (vuntz)]

Closing the bug, since the update has been released.

[Sky (andreansky)]

When will this new version be added to the repository? I have the same bug and cannot run this app do to it. Didn't even notice it was doing that but noticed a great slowdown - fan was working overdrive too. Fix it before it does anything more than just annoy the users.

[Chris Halse Rogers (raof)]

Which repository? 0.8.3.1 will be in Lucid shortly, and it is in the
do-core PPA for Karmic and (now building) Jaunty.

[Mark Cariaga (mzc)]

The bug description should be renamed or a new bug report should be
created for v0.8.3.1. The bug is still reproducible on 0.8.3.1. I
figured that by disabling all plugins and a few docklets, the frequency
of crashing is significantly reduced. Hence, there may be somehting not
running correctly on some plugin which causes gnome do to crash /
memeory leak....

On Mon, 2010-02-01 at 22:05 +0000, Chris Halse Rogers wrote:
> Which repository? 0.8.3.1 will be in Lucid shortly, and it is in the
> do-core PPA for Karmic and (now building) Jaunty.
>

[Chris Halse Rogers (raof)]

@mzc: It sounds like you have a different bug; this one did not cause Do to crash, just to spin the CPU wildly.

This particular bug is definitely fixed in 0.8.3. If you run into similar bugs in 0.8.3, please open a new bug report. Your bug will have a different cause to this one.

[B3rz3rk3r (adamgalt1)]

On 9.10 64bit, was using 8.2 and getting 200% usage on autostart. Starting manully fixed this.
Upgraded to 8.3.1 from the ppa as this was claimed to fix the issue, while the autostart bug does not seem to occur any longer, it does the same thing at random times now. I will be downgrading becuse as it stands right now i cant leave my laptop unattended for fear of it overheating.

There is no crashing as mzc stated, just the same behaviour as before. Ramps up CPU to 200% and keeps it there until manually killed.

[karlrt (karlrt)]

can confirm behaviour of comment #149, having installed the ppa too

[Hew (hew)]

Marking as fixed since 0.8.3 is in Lucid. Bug 450852 may be the 0.8.3 issue.

[Gufo (thrasherxxx)]

i've this issue on Maverick with Do 0.8.3.1 : my cpu go at 760%!!!!! O_O'

[Bwiedemann (bwiedemann)]

This is an autogenerated message for OBS integration:
This bug (540518) was mentioned in
https://build.opensuse.org/request/show/26171 11.2:Test / gnome-do