GNOME Do freezes the system (eats CPU and RAM)

The same problem here, it might have been caused by a recent upgrade. I had Epiphany and Tomboy plugins enabled, with handful of other apps working (Eiphany, Firefox, Bluefish, Inkscape, Liferea, Evolution), I'm not 100% sure whether Gedit was open at that time though.

I have been having the same problem. And it just randomly starts to happen after having been on for awhile. For me, it happens without ever using Gedit.

http://blog.davebsd.com/2008/09/16/a-cautionary-word-about-gnome-do-06/

On Tue, Sep 16, 2008 at 9:03 AM, BradwJensen <email address hidden> wrote:

> I have been having the same problem. And it just randomly starts to
> happen after having been on for awhile. For me, it happens without ever
> using Gedit.
>
> --
> Gnome-Do freezes the system (eats CPU and RAM)
> https://bugs.launchpad.net/bugs/270437
> You received this bug notification because you are a member of GNOME Do
> Core Team, which is subscribed to GNOME Do.
>

@david: that doesn't mean we should not report our bugs... and
downgrading is not a solution.
The core team should fix it upstream, and not encourage the guys who
have problems to hold the versions of their software.

What makes you think I don't want you to report your bugs? I was just
sharing some info. Yes, the core team should fix it, but the issue is a bit
more complicated. A fix is not available NOW, and people need to be able to
use Do NOW, so downgrading is the best solution available NOW. Also, the
core dev has no computer...

Confirming; this seems to be a real issue.

another trace,

"me too"

Granted, I have about 80% of the plugins enabled and indexing a LOT of files, but it was never this bad. In fact I never had any cpu issues with do before.

This particular bug is not related to plugins, because I have tested Do with a clean installation (and no plugins) and I'm experiencing the problem.
The crashes appears with both plugins enabled/disabled with the same behaviour (Do unrensponsive and CPU ~ 80%)

I and a co-worker of mine have had this problem in the past couple of weeks. Any sign of a resolution?

Correction to my last post, not in the past couple of weeks, more like the past few days.

So, this seems to be a regression in 0.6.0.1. I suspect it has to do with the clipboard-watching changes in SelectedTextItem. If you don't mind building from source, and don't mind losing the Selected Text item, please test the code in the lp:~raof/do/clipboard-hacking branch, and see whether that "fixes" this bug for you.

it seems to be rock-solid...

2008/9/19 Chris Halse Rogers <email address hidden>:
> So, this seems to be a regression in 0.6.0.1. I suspect it has to do
> with the clipboard-watching changes in SelectedTextItem. If you don't
> mind building from source, and don't mind losing the Selected Text item,
> please test the code in the lp:~raof/do/clipboard-hacking branch, and
> see whether that "fixes" this bug for you.

i am experiencing the same promlem since the 0.6.0.1 update, too.

same bug with do-uiwork

Same problem here after the 0.6.0.1 update. It works fine for a while then it just randomly starts leaking memory and eating the CPU. I didn't have a problem with 0.6.0.

Got the same problem after the update, i can provide a debug output, just tell me how much lines you need. This time it took nearly 8h till it got crazy and my logfile is quiet big, compressed about 50MB, uncompressed nearly 2GB.

Ok. So, we (probably) know what the problem here is - watching the clipboard. If people still want to be useful, they can test the code in lp:~raof/do/clipboard-hacking - that will get you a mostly-broken "Selected text" item, but it shouldn't crash in THIS way (it'll probably crash in other ways, such as if you actually try to _use_ the "Selected text" item).

If you can reproduce this behaviour - Do suddenly starts consuming CPU and memory without an apparent trigger - with the clipboard-hacking code, please respond. If this clipboard thing is the actual problem, then we've got a good idea of how to fix it, and will do so soon.

The fix on trunk has resolved the CPU eating for me.

Don't know if this is related, but Gnome-Do just ate up 32% CPU and 111 MB RAM.
I wouldn't have found this out if this didn't heat up the CPU 10 (!!!) degrees.

This is pretty bad for an application I haven't used once since I booted up today.
This probably happens all the time and explains why my laptop gets so hot for no reason.

Any plans on fixing this in a 0.6 point release, so that distros using 0.6 can resolve this? Just wondering, thanks!

On Sat, 2008-10-04 at 17:14 +0000, Mike Rooney wrote:
> Any plans on fixing this in a 0.6 point release, so that distros using
> 0.6 can resolve this? Just wondering, thanks!
>
Absolutely. It's just undergoing a little more testing to make sure we
don't introduce _more_ bugs (again) fixing this one!

I believe I've found a way to reliably reproduce this bug (although it seems that there is already a fix on the way, which is great!).

I've had Gnome Do begin consuming the CPU numerous times with seemingly unrelated triggers. However, one thing consistently triggers it: using the mouse to select text in Gedit. This is with v.2.22.3 of Gedit.

I'm not sure if this is the same bug, but I'm seeing a similar issue in Do 0.8.0.

When entering raw text in the first pane of Do, Do stops responding and starts filling RAM and continues to do so until the system is either unusable, or Do gets killed. Spits out an error like this just before I kill it:
"GNOME.DefineAction "Define" encountered an error in SupportsItem: Out of memory."

I can happily enter raw text into the second pane, if I've picked my action first, but it sure doesn't like the first one.

I cannot reproduce, it's possible this was fixed in trunk

--
--Alex Launi

Hmm... alrighty, I'll hang out for the 0.8.1 release and see what happens.

Thanks!

Hmm... Define.SupportsItem is simple a regex check, so maybe mono's regex
class has a bug. That's hard to believe.

Pretty much just confirming jason Wiggs post.

I am using 8.1 in Arch linux and have been experiencing the same issue, and happens during raw text mode. Any non-function key that is not a letter or number key will put Do into raw text mode then spike the ram to 90+% + 25% of swap and 80% of cpu. It happens every time one both of our computers both with the same OS and Do version.

I don't recall ever having this issue while Ubuntu was on our computers, but that was when whe had Do 6.1

I love Gnome -Do though. the functionality and time saving that do offers far out weighs this inconvenience.

If there is some output you need for assistance I can duplicated this bug very easily, and would be happy to get it to you

Can you tell us an exact sequence of keys that causes this, as well as your
keyboard layout?

--
-- Alex Launi

Also experiencing the problem in the gnome-do that's part of Ubuntu Jaunty (0.8.1.3), just echoing.

I should add more information on my situation I think, which isn't exactly the same as mentioned above now that I think about it....

gnome-do constantly uses between 20 and 50% of CPU except once in a great while (maybe a half-minute every thirty or so). I can tell it's constant because while it's open, my laptop's cooling fan runs basically all the time. It actually isn't -freezing- my system (although at startup it takes a long time before it becomes active, which makes Docky less than useful), but it is hogging a lot of resources which I presume, on a more limited system, could cause freezes.

I guess this is caused by its indexer. How long does it generally take for indexing to complete?

Hi there. I'm experiencing the same issue in Jaunty. Not sure what to grab. I just made the switch from Windows but this app is awesome. If there is anything I can gather please let me know. I'd appreciate the experience.

Thanks,

I can recreate the same symptom (lock-up in CPU busy-loop) on demand. It occurs whenever you click on the an application icon while the application window is open, but the application window is off the current display.

To recreate (tested with 0.8.1.3):

1) Start Gnome Do with display stretched across two screens (xrandr)
2) Start an application can place it on the second screen
3) Used xrandr to turn off the second screen and change the display size
4) Click on the icon in Gnome Do for the application
5) Observe one of the two Gnome Do processes goes into CPU busy-loop
6) If you kill and restart Gnome Do and click on the same application icon after restart, it will go straight back into a busy-loop again
7) If you move the application back within the visible display area and restart Gnome Do and click on the icon, you get no loop and have no problems

The process that loops is always the child one (the one without the gnome do icon in the process list)

Is this the same or a new bug?

Aaron.

This sounds like a new bug, please post as a new bug.

Just got reminded of this thread....

I think I have more information on what caused the situation in my case. It seems highly likely that it had to do with one or more of the plugins I had running at the time. Running Gnome-Do without any plugins means the problem doesn't occur, nor does it when I run only a few simple ones (like Window Manager). I'm still not sure exactly which plugins caused the problem; it's possible they were all community-provided.

Hi,
I bought a TV last week from a website:www.hkeles.com. I have
received the product. The quality is very good. They also sell
phones,motor,psp and so on. Because of the financial crisis, their
products are very cheap. by the way, they only sell new and original
products .If you need these products, you can have a look . I think
you will get many benefits.
Greetings!

lol SPAM has come to Launchpad ^^^ .. and Andrea Cimitan's launchpads account (legit user .. he creates the Murrine GTK theme) has been compromised !!

i have the freeze/ eats-cpu problem now in karmic koala after booting up. i have to kill gnome-do and restart it. i don't have this problem ín jaunty

Confirmed for me.

for me too, sometimes it freezes so i have to logout and login to make it work. And also, randomly it starts eating a lot of resources and heats up my laptop, but then stops, and I still haven't found what triggers it.

This only happens for me when I first log in. Both processors go up to 100% and gnome-do responds but doesn't search any of the stuff I type in (for example, if I wanted to hibernate, I would type 'h' and it would normally come up with it straight away, but now even if I type the full word it doesn't come up with it).

Hmmm... I was just wondering: If this is know marked "Fix Released", when are we going to be able to enjoy that fix?

Fix has already been committed in version 0.8.3.1.

https://launchpad.net/do/+announcement/4538

If the problem persists it seems that this bug report has to be reopened!

Hi Tomi,

The bug still recurring but not as frequent as before. On my case to
minimize crash, I disabled all the plugins and left only the weather
docklet. This workaround is not yet confirmed, please feel free to try
it.

I'm convinced that the bug has something to do with the plugins.

On Tue, 2010-01-26 at 19:20 +0000, Tomi Juntunen wrote:
> the problem persists it seems that this bug report has to be reopened

Same problem here it just freezes once ubuntu karmic is fully loaded. This only happens when Gnome Do is in Docky mode.

I reopened the bug since two people have confirmed that this has not been completely solved.

I'm having the same problem,

What information do you need ? Maybe I can help you ?

Can people still experiencing this bug please try with lp:~alexlauni/do/single-thread-reload ??

*** PLEASE NOTE that this branch builds off of current trunk, so if you use the Window Manager plugin, you will need to build lp:do-plugins as well, or disable the window manager plugin

Confirming that Gnome Do hogs CPU on Ubuntu 9.10

This happens approximately 40% of the time when Gnome Do auto-starts at user login. The first application I start after login is top. If gnome-do shows up at the top line eating 100% of the CPU time, I kill it and restart. Manual restart of Gnome Do has never caused this problem.

Try to disable all plugins.. please check if the bug is reproducible if
the plugins are all disabled.

On 13/03/2010 8:02 AM, yuri wrote:
> Confirming that Gnome Do hogs CPU on Ubuntu 9.10
>
> This happens approximately 40% of the time when Gnome Do auto-starts at
> user login. The first application I start after login is top. If
> gnome-do shows up at the top line eating 100% of the CPU time, I kill it
> and restart. Manual restart of Gnome Do has never caused this problem.
>
>

> Confirming that Gnome Do hogs CPU on Ubuntu 9.10
> This happens approximately 40% of the time when Gnome Do auto-starts at user login.

I get the same issue on login with 9.04. Approximately half the time one of the Gnome Do processes will lock-up if you start it on login. I've add the icon to the system tray. The if the Docky display does no appear when I log in, then I kill Gnome Do and manually restart, which always works.

A couple of the official plug-ins like weather are enabled. Can try disabling them.

Is there a debug log we can generate and supply?

I disabled Skype plugin and have not seen the problem for a few days now. I'll keep watching.

In more than 2 weeks of using Gnome-Do without Skype plugin the problem has appeared only once.

I had to close Do today as it was using 1.1 Gb of ram according to Gnome System Monitor.

I've grown to love Do, but this just makes it non-usable… Anything we can do to help with this one?

I don't have the Skype plugin active (never have) and have removed the microblogging plugin too.

GNOME Do 0.8.3.1

lsb_release -rd:
Description: Ubuntu 10.04 LTS
Release: 10.04

uname -a:
Linux wind-up-bird 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux

I have a very small idea what this might be. I'm not really sure how much of it can be fixed or where the leak itself is. When using the 'Super' + space to type in and launch an application, memory starts to get used. Doing 'Super'+space several times in a row will cause the memory to increase, but it looks like Do never gives the memory back.

I personally use Do to launch everything from a terminal several times a day, to just getting a web browser up and running. I'm not sure if the System Monitor has much do do with the amount of memory being used, but i have now disabled that plugin.

If I had my guess something is being remembered in a db in memory. That db or file needs to be dumped from time to time or just truncated.

Sometimes when resumed from suspend, the gnome-do process uses 200% CPU (both core). So I have to kill and restart it. Maybe it is the same problem.

OS: Ubuntu 10.10
Gnome-do version: 0.8.3.1
Mono version: 2.6.7

I'm marking this bug as "fix released". There various sources of this symptom, and each of the known ones has been fixed.

If you still see this problem in an up-to-date Do - version 0.8.5 at this time - please file a new bug. We ideally want a single bug per *cause* of problems, not per-symptom. Otherwise it can be hard to tell when we're fixing problems.

This problem still no resolved, I'm using Ubuntu 12.04, I added the PPA version, but the program sometimes uses 6 GB of memory, as you can see in this screenshot: http://goo.gl/EAJqgZ