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

[Alex Launi (alexlauni)]

Unless it's a setting unrelated to Do that is making our
ApplicationItemSource freak out

--
-- Alex Launi

[Chris S. (cszikszoy)]

I can't possibly see how this would be caused by gconf... Or for that
matter some setting of ours in gconf?

On Fri, Aug 21, 2009 at 2:54 PM, Robert Dyer<email address hidden> wrote:
> You shouldnt need to delete ~/.gconf, at best you should delete:
> ~/.gconf/apps/gnome-do
>
> --
> 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.
>

[Jonathan Lumb (jonolumb)]

Here is my .xsession-errors output

[tekstr1der (tekstr1der)]

Chris S. - Do you need any more debug info from users? As of 08-05-2009, when this bug was triaged, it appeared you had enough to go on.

Still seeing this every 3-5 reboots. Any progress on a fix that could make it into Karmic alpha 5 or 6?

[dafero (daferoes)]

My reported bug was marked like duplicated but I think That is not the same bug.

https://bugs.launchpad.net/do/+bug/428037

I don't have activated the Microblogging Plugin...
The problem, which I reported to you, is that gnome-do does not auto start well.

In my case gnome-do not use 90% CPU when starts, just it don't appear in the desktop

I read the same problem in some forums, users had described it as I describe.
I am using Jaunty and DO 0.8.2.

Greetings from Spain.

[Aj-novell (aj-novell)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20090909 SUSE/3.5.3-1.1 Firefox/3.5.3

top shows:

Tasks: 160 total, 1 running, 159 sleeping, 0 stopped, 0 zombie
Cpu(s): 99.7%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2013576k total, 1117400k used, 896176k free, 51964k buffers
Swap: 2104444k total, 0k used, 2104444k free, 541024k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 2243 aj 20 0 324m 29m 17m S 198 1.5 80:29.10 gnome-do

Note: uptime is:
uptime
 20:32pm up 0:50, 3 users, load average: 14.68, 14.15, 11.84

So, 50 minutes up - and 80minutes of gnome-do runtime already.

Reproducible: Always

Steps to Reproduce:
1. run top to verify what gnome-do does
2.
3.
Actual Results:
high cpu usage of gnome-do

[Thiago Teixeira (tvst)]

I have upgraded to the latest version from Bazaar, but the problem still persists.

Gnome Do 0.8.2
bzr do r1303

[Thiago Teixeira (tvst)]

By the way, the version I'm using I got with

bzr branch lp:do

Just to be clear...

[Jonathan Lumb (jonolumb)]

This is still happening to my machine on Ubuntu Karmic (Alpha 6)

I rarely get a clean start of Gnome Do on my machine - it either has the 100% CPU problem as in this bug, or the dock does not appear at the bottom of the window and I have to manually kill the background gnome-do process that is running in Task Manager (the process without the purple gnome-do icon) before restarting Gnome-Do once more.

It seems that this bug has been around for quite a while and lots of traces have been provided - is anything being done about it?

[Jonathan Lumb (jonolumb)]

Here is a debug trace from my last startup (where the CPU bug came up once again)

[Alex Launi (alexlauni)]

Is anyone here NOT using docky, and is anyone here NOT using the trash docklet?

[Garbin Huang (garbinhuang)]

I use docky and trash

On 9/27/09, Alex Launi <email address hidden> wrote:
> Is anyone here NOT using docky, and is anyone here NOT using the trash
> docklet?
>
> --
> 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: Triaged
>
> Bug description:
> OS:Ubuntu 8.10
> GNOME Do:0.8.2 install from sourcecode
>
> many be caused by Microblogging Plugin。I disabled this plugin, the problem
> is gone。
>

[neclepsio (neclepsio)]

I don't use docky and I have no plugin active.

On Sun, Sep 27, 2009 at 7:33 AM, Garbin Huang <email address hidden> wrote:

> I use docky and trash
>
> On 9/27/09, Alex Launi <email address hidden> wrote:
> > Is anyone here NOT using docky, and is anyone here NOT using the trash
> > docklet?
> >
> > --
> > 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: Triaged
> >
> > Bug description:
> > OS:Ubuntu 8.10
> > GNOME Do:0.8.2 install from sourcecode
> >
> > many be caused by Microblogging Plugin。I disabled this plugin, the
> problem
> > is gone。
> >
>
> --
> 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: Triaged
>
> Bug description:
> OS:Ubuntu 8.10
> GNOME Do:0.8.2 install from sourcecode
>
> many be caused by Microblogging Plugin。I disabled this plugin, the problem
> is gone。
>

[Jonathan Lumb (jonolumb)]

I am using Docky but without the trash docklet.

[toxicafunk (lenuspill)]

I don't use Docky or Trash and still have the problem.

On Sun, Sep 27, 2009 at 11:47 AM, Jonathan Lumb <email address hidden> wrote:

> I am using Docky but without the trash docklet.
>
> --
> 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: Triaged
>
> Bug description:
> OS:Ubuntu 8.10
> GNOME Do:0.8.2 install from sourcecode
>
> many be caused by Microblogging Plugin。I disabled this plugin, the problem
> is gone。
>

[Aj-novell (aj-novell)]

not reproduceable anymore with current factory.

[Leo (leopoldo-pena)]

I use Docky but not trash docklet.
+1 here. CPU shoots up to 100% after startup. Sometimes it just starts up fine.
I love Docky but this is a very annoying problem. Using 0.8.2 in Jaunty.

[Jonathan Lumb (jonolumb)]

Indeed - I can no longer leave my laptop to startup unattended, otherwise it risks overheating as the temperatures soar to over 80 degrees celcius!

[Gankov-andrey (gankov-andrey)]

I use openSUSE 11.2 milestone 8 64-bit. And i has some bug. But on my system bug reproduce some times. Approximately 50/50.
When i load openSuse, i open system monitor and see process gnome-do use 140-200% CPU.
Please reopen this bug.
If need some log or other information, i can give.

[Aj-novell (aj-novell)]

I could reproduce it once again last week as well. It does not happen that often anymore as before.

[Andrew Senyshyn (asenyshyn)]

Appears for me in Ubuntu Karmic beta. Do version 0.8.2
Sometimes uses 90-100% cpu immediately after startup and sometimes after some time of working with computer.
After restarting Do never happens again until next (of few more) reboot.

[Thiago Teixeira (tvst)]

Still having this problem. Using latest trunk.

I even tried manually deleting all files related to Gnome-Do from my system, to make sure there wasn't some conflict where some plugin was installed that was written for an older version of Do. I was pretty thorough deleting the files. After I was done, a "locate gnome-do" only reported files related "gnome-doc". Still, after reinstalling the trunk version of Do, I got the problem on my next reboot.

This may be a bit obvious, but sometimes the obvious gets overlooked: Gnome-Do 0.8.1 worked fine, and 0.8.2 introduced this bug. How about looking at a diff between the two? Where there *that* many changes that makes this too time-consuming?

[Robert Dyer (psybers)]

Actually there were 174 revisions, the diff is 20k lines. Feel free to browse it and help find the bug. :-)

[Chris S. (cszikszoy)]

It's not the number of changes that makes this time consuming. What
makes this time consuming is that exactly 0 developers are able to
reproduce this bug.

On Wed, Oct 7, 2009 at 11:40 AM, tvst <email address hidden> wrote:
> Still having this problem. Using latest trunk.
>
> I even tried manually deleting all files related to Gnome-Do from my
> system, to make sure there wasn't some conflict where some plugin was
> installed that was written for an older version of Do. I was pretty
> thorough deleting the files. After I was done, a "locate gnome-do" only
> reported files related "gnome-doc". Still, after reinstalling the trunk
> version of Do, I got the problem on my next reboot.
>
> This may be a bit obvious, but sometimes the obvious gets overlooked:
> Gnome-Do 0.8.1 worked fine, and 0.8.2 introduced this bug. How about
> looking at a diff between the two? Where there *that* many changes that
> makes this too time-consuming?
>
> --
> 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.
>
> Status in GNOME Do: Triaged
>
> Bug description:
> OS:Ubuntu 8.10
> GNOME Do:0.8.2 install from sourcecode
>
> many be caused by Microblogging Plugin。I disabled this plugin, the problem is gone。
>

[Jonathan Lumb (jonolumb)]

I can reproduce this bug on a daily basis - what exactly is it you need so that some progress can be made?
Let me know how I can provide more useful debug information, I am more than happy to help on this issue.

Thanks

[Martin Pool (mbp)]

Jonathan, try finding the Do process with ps, then use "strace -o trace -p
1234" with its pid. Then attach that to this bug.

On Oct 8, 2009 7:10 AM, "Jonathan Lumb" <email address hidden> wrote:

I can reproduce this bug on a daily basis - what exactly is it you need so
that some progress can be made?
Let me know how I can provide more useful debug information, I am more than
happy to help on this issue.

Thanks

-- GNOME do 0.8.2 use 90% CPU when my computer startup。
https://bugs.launchpad.net/bugs/395190 You...

[Thiago Teixeira (tvst)]

@robert
:) I will even take a look at it and see if anything jumps out. But not knowing the innards of the program will make this even more difficult. Do you have any pointers where this trouble could be coming from?

@chris
I see. Personally, I have two computers, both running the same version of Gnome-Do and of Ubuntu, and mainly the same software overall -- but only one of them has this problem.

So lets go through the facts about this bug:
1) It only happens when the computer is starting up.
2) It only happens every so often. (i.e. not at every start up)

So can we make Gnome-Do start-up automatically from a debugger? This bug is probably due to a race condition somewhere, so the slowdowns of the debugger may make the bug go away, but --who knows?-- we may get lucky...

Can you walk us through the process of making Do start from a debugger automatically when the Gnome session starts?

[Jonathan Lumb (jonolumb)]

Thanks Martin, I will get back to you next time the bug shows its face :-)

[Thiago Teixeira (tvst)]

I was writing a script to do what Martin proposed (so I don't have to remember it!) and found out that "ps -A | grep gnome-do" returns two results. Is this normal? It seems to happen anytime Do runs.

This is what I did:

$ ps -A | grep gnome-do
15850 ? 00:00:00 gnome-do
15856 ? 00:00:03 gnome-do

$ pkill -9 gnome-do

$ ps -A | grep gnome-do
[nothing]

$ gnome-do

$ ps -A | grep gnome-do
16157 ? 00:00:00 gnome-do
16163 ? 00:00:02 gnome-do

If this is normal, which process should I "strace"?

[Robert Dyer (psybers)]

Yes, this is normal. The first process is the shell script, the second is the mono app (the actual program):

rdyer@narmada:~$ ps -A|grep gnome-do
 3757 ? 00:00:00 gnome-do
 3766 ? 00:00:56 gnome-do

rdyer@narmada:~$ ps ax|grep gnome-do
 3757 ? S 0:00 /bin/sh /usr/local/bin/gnome-do
 3766 ? Sl 0:57 mono /usr/local/lib/gnome-do/Do.exe

[Jonathan Lumb (jonolumb)]

I therefore assume that it is the second process (Do.exe) that is to be debugged, right?

[Alex Launi (alexlauni)]

Yes. debug Do.exe

--
--Alex Launi

[Mathieu Leplatre (mathieu.leplatre)]

A trace and some info about mine :

 :~$ ps -ef | grep gnome-do
 mathieu 3689 3520 0 09:46 ? 00:00:00 /bin/sh /usr/bin/gnome-do
 mathieu 3696 3689 99 09:46 ? 00:04:18 /usr/bin/cli /usr/lib/gnome-do/Do.exe

$ top
 ...
 PID PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 3696 20 0 58988 29m 15m S 287 1.5 4:53.93 gnome-do

[Jonathan Lumb (jonolumb)]

A lot of output about gettimeofday in there... could that be where the problem is?

[Mathieu Leplatre (mathieu.leplatre)]

Curiously, after killing and restarting, there's globally the same amount of "gettimeofday", but no CPU overload.

[Thiago Teixeira (tvst)]

Here's my strace.

[Thiago Teixeira (tvst)]

Looking at both traces, a few things jump out

1) many "EAGAIN" lines, such as
read(3, 0xa03a768, 4096) = -1 EAGAIN (Resource temporarily unavailable)

2) way too many gettimeofday()

Also, just out of curiosity: why is my trace more organized than Mathieu's? Something to do with multi-core processors?

[hanzomon4 (hanzomon4)]

My Trace

[jc00ke (jesse-jc00ke)]

I'm affected by this bug too. Only on startup, and it eats ~185% of my CPU, bloats to ~20Mb. I can submit my data later if wanted (almost time for brunch) but I was wondering if the developers have made any progress? We all really appreciate your hard work, and Do is a seriously badass project. But I now feel like I can't even use my computer when it's not working. I've come to rely on Do, so I hope this bug can be squashed soon.

Thanks again!

[Sergey Sventitski (sergey-sventitski-deactivatedaccount-deactivatedaccount)]

Guys, as i can see there are too much logs and traces were attached. Any outlook on this really annoying issue ?

[Vincent Untz (vuntz)]

*** Bug 547888 has been marked as a duplicate of this bug. ***

[Vincent Untz (vuntz)]

Sany: any idea on how to debug this? (stupid question, but I'm not really good with mono apps ;-))

[Saarmstrong (saarmstrong)]

Assuming this bug refers to Do using all the CPU when it starts up, here's the upstream bug:

https://bugs.launchpad.net/do/+bug/395190

Lots of comments, traces, debugging...very little progress from what I can tell.

This is definitely a gnome-do bug...I had the same problem even in openSUSE 11.1 (I got gnome-do 0.8.2 from a third-party source, but all the underlying libraries including Mono were stock 11.1).

[Sandy Armstrong (sanfordarmstrong)]

In case this is of interest, there is a distro bug filed against openSUSE 11.2 for this issue: https://bugzilla.novell.com/show_bug.cgi?id=540518

I've been experiencing this every few logins ever since I upgraded to gnome-do 0.8.2 (even when I was on openSUSE 11.1).

[Saarmstrong (saarmstrong)]

As for following up on debugging, I'm going to focus my attention on the upstream bug.

[Marco Diaz (zethabyte)]

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

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!

[Serge (dark-serge)]

I have got the same bug as everyone.
Just in case that someone wanted to use Gnome-do w/o starting it up manually on every system startup :
make file with :

#!/bin/sh
sleep 25
gnome-do &

put that file in startup programs and gnome-do will start w/o taking ~100% of CPU (remember to turn off 'start after login' on Gnome-Do preferences.

[Sadashiv (sadashiv-30)]

I too am having the same problem of 90% CPU when system starts. But this was not a prblem till I used KGrubEditoor to edit my grub menu. Enabled plugins are Files 7 Folders,Battery Docklet,Disk Mounter,GNome Terminal,Google Seach , Locate Files,Weather DOcklet, System Docklet.

Hope this helps for the developers.

[Amin (amshali)]

It happens to me too! It only happens when it automatically starts.

[nean (nean.and.i)]

hi guys,

i've the same issue now in karmic and I just recognized that it may has something to do with start order.
eg. i've added a "sleep 10" at the early beginning of "/usr/bin/gnome-do" and the problem with CPU load is gone on an autostart

there's also a second weird thing with the autostart feature:
i've added the "Home Folder" in Docky but after the autostart of gnome-do it won't open, but if I close gnome-do and open it again it works as usual.

hope this may help to find the root cause,...

cheers,
nean

[delphi (delphi)]

hi

I'm having the same issue with karmic.

I get different strace lines like:

gettimeofday({1257181322, 856496}, NULL) = 0
inotify_add_watch(18, "/home/*user*/.config/ibus/bus", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory)
read(3, 0xa103f60, 4096) = -1 EAGAIN (Resource temporarily unavailable)

ibus is installed

[Crashbit (crashbit-gmail)]

It happens to me too! It only happens when it automatically starts.
I use Docky and Trash icon.

crashbit@m1330:~$ uname -a
Linux m1330 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

[Sergey Sventitski (sergey-sventitski-deactivatedaccount-deactivatedaccount)]

Issue was solved after "sleep 10" was added at the early beginning of /usr/bin/gnome-do

[Jonathan Lumb (jonolumb)]

sleep 10 solves the problem for me too - i haven't had this issue for quite a few days now

[Wolter HV (wolterh)]

I tried the sleep thing but it doesn't start at all, which makes me think I am using it wrong.
I tried once putting in the [Startup Applications] [Add] [Command: sleep 10 && gnome-do], but it didn't work.
I also tried making a script and putting it in my ~/bin directory, with the following contents:
sleep 10
gnome-do
But it didn't work either.

How should I do this?

[dafero (daferoes)]

I tried the "sleep method" and it seems to work.
I' ve tried 3 times and 3 times worked.

I paste you, the content of my /usr/bin/gnome-do

#!/bin/sh

SCRIPT_PATH=`dirname $0`
SCRIPT_PATH=`cd $SCRIPT_PATH; pwd`

sleep 10
if [ "x$SCRIPT_PATH" = "x/build/buildd/gnome-do-0.8.2+dfsg/Do/bin/Debug" ]
||
   [ "x$SCRIPT_PATH" = "x/build/buildd/gnome-do-0.8.2+dfsg/Do" ] ; then
    echo "*** Running uninstalled ***"
    GNOME_DO_EXE="/build/buildd/gnome-do-0.8.2+dfsg/Do/bin/Debug/Do.exe"
else
    GNOME_DO_EXE="/usr/lib/gnome-do/Do.exe"
fi

# Send the dbus Summon signal right away for fastest response if
# Do is already running.
dbus-send --session --type=method_call --dest='org.gnome.Do' \
    '/org/gnome/Do/Controller' 'org.gnome.Do.Controller.Summon'

# If Do is not running, run it.
if pgrep -u "`id -un`" '^gnome-do$' >/dev/null; then
    /usr/bin/cli "$GNOME_DO_EXE" "$@"
fi
while [ "$?" -eq "20" ]; do
    /usr/bin/cli "$GNOME_DO_EXE" "$@"
done

I hope this helps.

Greetings from Spain!

2009/11/3 Wolter Hellmund <email address hidden>

> I tried the sleep thing but it doesn't start at all, which makes me think I
> am using it wrong.
> I tried once putting in the [Startup Applications] [Add] [Command: sleep 10
> && gnome-do], but it didn't work.
> I also tried making a script and putting it in my ~/bin directory, with the
> following contents:
> sleep 10
> gnome-do
> But it didn't work either.
>
> How should I do this?
>
> --
> 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: Triaged
> Status in X.Org X server: Invalid
>
> Bug description:
> OS:Ubuntu 8.10
> GNOME Do:0.8.2 install from sourcecode
>
> many be caused by Microblogging Plugin。I disabled this plugin, the problem
> is gone。
>

[René Vangsgaard (rene-vangsgaard)]

I experienced this bug on Jaunty, but since I updated to Karmic (November first) I have not experienced it. I have enabled only the standard plugins, both in Jaunty and Karmic.

[Eric Morgan (gemorgan)]

Gnome-do very often won't start for me. I quite frequently have to ALT-F2,
then killall gnome-do and try again. But this is a bug for a different
topic.

Good Luck!

On Tue, Nov 3, 2009 at 12:00 PM, dafero <email address hidden> wrote:

> I tried the "sleep method" and it seems to work.
> I' ve tried 3 times and 3 times worked.
>
> I paste you, the content of my /usr/bin/gnome-do
>
> #!/bin/sh
>
> SCRIPT_PATH=`dirname $0`
> SCRIPT_PATH=`cd $SCRIPT_PATH; pwd`
>
> sleep 10
> if [ "x$SCRIPT_PATH" = "x/build/buildd/gnome-do-0.8.2+dfsg/Do/bin/Debug" ]
> ||
> [ "x$SCRIPT_PATH" = "x/build/buildd/gnome-do-0.8.2+dfsg/Do" ] ; then
> echo "*** Running uninstalled ***"
> GNOME_DO_EXE="/build/buildd/gnome-do-0.8.2+dfsg/Do/bin/Debug/Do.exe"
> else
> GNOME_DO_EXE="/usr/lib/gnome-do/Do.exe"
> fi
>
> # Send the dbus Summon signal right away for fastest response if
> # Do is already running.
> dbus-send --session --type=method_call --dest='org.gnome.Do' \
> '/org/gnome/Do/Controller' 'org.gnome.Do.Controller.Summon'
>
> # If Do is not running, run it.
> if pgrep -u "`id -un`" '^gnome-do$' >/dev/null; then
> /usr/bin/cli "$GNOME_DO_EXE" "$@"
> fi
> while [ "$?" -eq "20" ]; do
> /usr/bin/cli "$GNOME_DO_EXE" "$@"
> done
>
> I hope this helps.
>
> Greetings from Spain!
>
>
> 2009/11/3 Wolter Hellmund <email address hidden>
>
> > I tried the sleep thing but it doesn't start at all, which makes me think
> I
> > am using it wrong.
> > I tried once putting in the [Startup Applications] [Add] [Command: sleep
> 10
> > && gnome-do], but it didn't work.
> > I also tried making a script and putting it in my ~/bin directory, with
> the
> > following contents:
> > sleep 10
> > gnome-do
> > But it didn't work either.
> >
> > How should I do this?
> >
> > --
> > 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: Triaged
> > Status in X.Org X server: Invalid
> >
> > Bug description:
> > OS:Ubuntu 8.10
> > GNOME Do:0.8.2 install from sourcecode
> >
> > many be caused by Microblogging Plugin。I disabled this plugin, the
> problem
> > is gone。
> >
>
> --
> 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.
>

[René Vangsgaard (rene-vangsgaard)]

Ha, ha - please ignore my previous comment. I restarted Karmic the fifth time since distupgrade, and gnome-do used over 100% of my CPU (dual-core). So I still experience this bug.

[Thiago Teixeira (tvst)]

I clean-installed Karmic, and the bug seems to have gone away. I still have the problem that the home folder problem, though.

[delphi (delphi)]

sleep 10 does not completely work around the problem. despite the 10 seconds sleep today gnome-do was using 100% of CPU after startup

[Graeme Glass (graemeglass)]

gnome-do Version: 0.8.2+dfsg-1 install on Karmic, and just a few minutes ago my cpu fan started spinning up and video playback went all jittery, so went to see what was up and gnome-do was using 100% cpu

[Ymmot (mail-tommymueller)]

Same problem here. 100% of CPU-usage when autostarting Gnome-do :-( , in Karmic its the same like in Jaunty...

[Leslie Viljoen (leslieviljoen)]

Just to note: this is not related to a Karmic upgrade - I have this problem and I did a clean install.

[Mxwu (mxwu)]

Improve the importance.

This is random occur not only on my system.
We'd better have a fix or disable gnome-do's autostart at the moment.

[Saarmstrong (saarmstrong)]

Putting a sleep in gnome-do's start script to delay autostart has worked for a lot of users, according to the upstream bug. Sorry, I haven't actually put any time into debugging this.

[tehf0x (gabe-squirrelsoup)]

Bump up, I also get this problem.
Either on boot, or when I come out of suspend, gnome-do manages to use 100% of both my cores. I restart the process and then it's fine, *but* sometimes when coming out of suspend I get the exact same behaviour.

If any debug logs / stack traces etc. are of help I can get them and post them here.

[Félix Velasco (felix-velasco)]

I've also run into this problem since upgrading to karmic, and I've realized that every stacktrace is blocked at "Dictionary.ContainsKey", including mine.

We're seeing several threads updating a single static Dictionary (Instances) in ApplicationItem.cs. The Dictionary class is not thread-safe, and running a simple test (http://pastebin.com/m2b246466) results in various different situations, from exception launching to data losing, to 100% cpu blocking situations.

The same potential problem lies in CategoryItem, and even if it doesn't appear in any stacktrace, the code is also non thread-safe. Since I don't know bzr good enough, I'll just attach a patch that should solve. At least, it works for me.

[Jbottomley (jbottomley)]

I'm seeing this as well, but intermittenly. Sometimes gnome-do will run for days before chewing up all my CPU time, sometimes it starts doing it immediately.

The Launchpad report now has a suggested bug fix:

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

[Thiago Teixeira (tvst)]

> Just to note: this is not related to a Karmic upgrade - I have this problem and I did a clean install.

Funny, I did a clean install of Karmic (including wiping the home folder) and the problem went away. Also, I have (as far as I can tell) set up all my startup applications exactly as before --- so I would assume that any startup-related race condition should persist in Karmic, but it doesn't seem to be the case.

By the way, I'm using Gnome Do bzr version r1305.

[Catscrash (catscrash)]

i did a clean install too, and the problem is still there, i didn't even copy my .folders

[Martin Vielsmaier (martin-vielsmaier)]

On 9.04 using 0.8.2 I also experience Do eating my processor sometimes when my computer comes back up from hibernate or standby. Most of the time the cpu load is not 100% immediatly after coming back up but it rather takes 1-4 minutes until I experience the bug.

[Thiago Teixeira (tvst)]

Ok this may be just a coincidence, but it could also be important:

1) After I clean-installed Karmic, I forgot to reinstall the music player applet (for the Gnome panel). Gnome-Do was running fine, not displaying the buggy behavior from this bug report.

2) Then I installed music player applet and rebooted, and Gnome-Do went back to taking over 100% of my processing. This is the first time that the bug happens to me in the 2 weeks since I installed Karmic.

3) I removed the music player applet and rebooted a few times. Gnome-Do loaded just fine.

I will later try repeating steps (2) and (3) a few times and to see if the same behavior persists. At least this way there would be *somewhere* to start looking for the problem...

[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