Bug 217031
Summary: | beagle sometimes consumes 100% CPU | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Need Real Name <mal> | ||||||
Component: | beagle | Assignee: | Alexander Larsson <alexl> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 6 | CC: | alex, averma, gnomeuser, joeshaw, k.georgiou, ncunning, tadej.j, valent.turkovic, wwoods | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2007-10-21 04:27:35 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Need Real Name
2006-11-23 09:07:16 UTC
rpm -e beagle beagle-gui beagle-evolution fixes the problem After beagle removal the FC6 feels so much faster, I thought FC6 was slow compared to FC5 because of new gnome bloat, but beagle removal totally changed the impression. It feels now like 3 times CPU increase. And no mysterious stalls any more. I would strongly recommend to remove beagle altogether. It's limited functionality does not worth ruining FC6 overall impression. There is also huge win in X startup. Now the command startx brings the X desktop at least five times faster. I get the same problem, 100% CPU usage. It appears that beagled-helper somehow hangs because I need to: killall -9 beagled-helper killall -9 beagled to stop it. This is not bug #212370 because it doesn't "hang" in the same way and I've already upgraded to beagle-0.2.10-7.fc6. I am using a suspend2 kernel from http://mhensler.de/ if that makes a difference. I have noticed that sometimes starts after I've resumed. But there's no real pattern to be able to duplicate it reliably. With all due respect to comment #1 and comment #2 removing beagle isn't a solution, it's a temporary workaround at best. This is actually probably a duplicate of bug #205258. Please test the beagle-0.2.13-1.fc6 update in updates-testing. Maybe it helps. According to the Beagle FAQ http://beagle-project.org/Troubleshooting_CPU "Beagle version 0.2.13 and older are buggy" "The first thing is to ensure that you're running at least Beagle 0.2.14 or newer. [...] Bugs in older versions existed that could cause directories to be continuously reindexed." Probably worth rebuilding on the basis of a newer Beagle? Still happens on FC7test4 x86_64 using beagle-0.2.16.2-4.fc7, it spins one CPU constantly. I'm on a dual-core machine but it only spins the one CPU sp I didn't notice it till now.. wow. Adding FC7Blocker Following the guide at http://beagle-project.org/Troubleshooting_CPU we find that: 20070510 03:07:53.5609 06808 IndexH ERROR: Unable to open /home/dnielsen/Documents/New Document.odt. Probably an invalid OpenOffice document. is causing this, I believe this bug is fixed in 0.2.17 according to the changelog: http://mail.gnome.org/archives/dashboard-hackers/2007-May/msg00013.html * Fix an infinite loop problem with empty OpenOffice documents. [bgo #427256, #435694] This also contains memory use and performance enhancements so consider this a request for an update from your friends on the QA team. Should probably be handled as a post f7-update at this point 0.2.17 also contains a 100% cpu load bug on my machine, Beagle it seems is just conspiring to make our default install suck. Would it be sane to disable it in our default install, I know it late in the game but shipping with a 100% load bug is bad and there's no fix we can deploy post release as of yet for that what one. I don't think relying on post release updates here is safe. I would suggest just to remove beagle. The FC6 was just unusable with beagle running. At least do not ruin FC7 impression. I would repeat it again about beagle: It's limited functionality does not worth ruining FC overall impression. (adding wwoods) Either request a exception from rel eng to fix this bug by providing an update before the general release or we should just disable it by default for now and have this in the "known issues" section of the announcement and/or release notes. Can we have a final decision on this soon? I really don't have a lot of time to work on beagle, and it seems to keep having these kinds of bugs. We should probably disable it. I think not installing it by default might be the right thing to do. I removed beagle from the default install in fedora 7, as bugs like this makes the distro look pretty bad, and they keep turning up. I use beagle on Fedora Core 6 and Fedora 7 test 4 system all the time and have ZERO problems. I had problems on Fedora 5 while testing beta versions of beagle. After FC6 launch I had only great experience with it... Created attachment 155029 [details]
Patch against 0.2.16.x to fix the empty OOo file
If you don't want to update to 0.2.17, I've attached a patch which fixes the
empty OOo file problem. We apply this to 0.2.16.3 in SUSE.
(In reply to comment #11) > 0.2.17 also contains a 100% cpu load bug on my machine I can work with you on this one, but I didn't know about it until I happened to just come across it now. What file is causing the issue? I attempted to follow the troubleshooting guide but the process that runs rampant is not the helper one but beagled itself. There's no indication of error in the log but if one looks at what beagle is doing using the status program it appears that it is indexing mail. I think the sanest approach is to wait for the package to officially be updated once Development opens again and then have a look at matters. Seeing as Beagle is frozen for F7 I'd rather encourage the testers to work with you on making Beagle rock in F8, if you have the excess energy comaintaining the Beagle package would be good in that it would allow you to push patched versions. Having Beagle be useful during as much of the development cycle hopefully give you better feedback from the Fedora userbase so to increase rockage. Interesting, I haven't seen beagled itself take up 100% CPU in a long, long time. The one reason I can think of that it might is the screensaver case. Checking your logs (~/.beagle/Log/current-Beagle) would help too, as you might be hitting an exception unexpectedly? Joe and David if you need some to test beagle with Fedora 6 and 7 I'm volunteering for testing new versions - just give me instructions on how I need to test it and in which way to give you feedback. I can share my experience with beagle from over several months: ibm R52 laptop + fedora 6 + beagle + deskbar = no cpu issues HP nx7300 laptop + fedora 6 + beagle + deskbar = no cpu issues HP nx7300 laptop + fedora 7 + beagle + deskbar = no cpu issues (few weeks only) noname desktop + opensuse 10.2 + beagle + deskbar = no cpu issues HP laptop of my girlfriend + linux mint (ubuntu edgy) + beagle = no cpu issues HP laptop of my girlfriend + linux mint (ubuntu feisty) + beagle = no cpu issues (few weeks only) Hi I would help with beagle project - I would like to help out and make it installed by default in Fedora 8. I have a few Fedora 7 installs and one Fedora Core 6, so if you send me all problematic files with which ones you had problems I can test it and send you feedback. Can you tell me what is the status od beagle now? Are these bugs fixed by now and will beagle be installed by default in Fedora 8? This bug has been fixed but at least in Rawhide Beagle is being problematic.. again: See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245521 Correct me if I'm wrong. I see that rawhide beagle bug is reported only for 64bit platform. Does the 32bit version work ok? Created attachment 158476 [details]
screenshot of beagle on Fedora rawhide desktop running ok.
screenshot of beagle on Fedora rawhide desktop running ok.
I have updated Fedora test 4 to latest rawhide and beagle works just fine. Check out the screenshot. I do get an strange output from beagle-info but it works just fine. $ beagle-info --daemon-version ***MEMORY-WARNING***: /usr/lib/beagle/Info.exe[3290]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... Daemon version: 0.2.17 (In reply to comment #27) > ***MEMORY-WARNING***: /usr/lib/beagle/Info.exe[3290]: GSlice: g_thread_init() > must be called before all other GLib functions; memory corruption due to late > invocation of g_thread_init() has been detected; this program is likely to > crash, leak or unexpectedly abort soon... I believe this is a problem with gtk#, but I will have to investigate further. In any case, it's unrelated to this bug (100% CPU utilization). It probably is a gtk bug, but I posted that only for you to see the version of my beagle. I belive my post with attachement is vital to this but in the way it shows that on 32bit fedora rawhide system beagle works without 100% CPU bug - as you all can see. (In reply to comment #29) > I belive my post with attachement is vital to this but in the way it > shows that on 32bit fedora rawhide system beagle works without 100% CPU bug - as > you all can see. Well, part of the problem is that certain situations or data are evidently causing the CPU issue. See above about the empty OOo file for an example. The title of the bug is "beagle sometimes consumes 100% CPU", not "beagle always consumes 100% CPU". :) As always, the info on the wiki http://beagle-project.org/Troubleshooting_CPU is helpful in debugging these issues. I've also been working on a 0.3.0 version which will more strictly require inotify (and warn if unable to get enough watches) so that the problem of looping over directories w/o inotify watches will go away. That's a common cause of high CPU utilization when the screensaver is on. Great! I can't wait to test it out. Will it be also available for FC6 as for F7? I've been running Beagle on F8 for a while now without hitting the 100% CPU usage bugs and generally Beagle is very well behaved. I think the sensible thing is to close this bug. For F9 I plan to put Beagle under the loving embrace of the GNOME QA beat, I'd like people to join me in testing. The end result would hopefully be having Beagle and other Mono apps moved under the supervision of some kind of Mono SIG so to unload Alex and ensure quicker response to bugs and version upgrades. I'll ping Paul Johnson about this as he seems very dependant on Mono and might be conned into maintaining Mono on Fedora. Regardless I'm closing this bug as RAWHIDE with encouragement to upgrade to F8 as soon as it's out for an improved bugfree Beagle experience. Great news! I'll be happy to test new beagle on F8 (I'm using it now on rawhide) and on F9 devel when it starts. I would love to see it running in gnome under F9 so if you need bug testers just drop me a line. |