Description of problem: Beagled hangs after it has been running for a few minutes. Version-Release number of selected component (if applicable): 0.2.10-5.fc6 How reproducible: Always Steps to Reproduce: 1. start beagled 2. wait a few minutes Actual results: beagled hangs, commands like beagle-status that are executed afterwards hang too. When I start beagled manually from the command line, I see the following in the moment it hangs: Xlib: unexpected async reply (sequence 0x15)! The sequence number changes from time to time. I've attached the logs from beagled --debug.
Created attachment 139472 [details] beagle log
Created attachment 139473 [details] index helper log
Created attachment 139474 [details] index helper exceptions log
the same symptom here: neiter beagle-ping nor any of the status stuff works anymore some minutes after beagle is started.
the same happens here on 3 different boxes
I have the same problem. Nothing is ever indexed even though beagled is running. Just after rebooting if I do: beagle-info --status I get: Scheduler: Count: 0 Status: Waiting for the next trigger time Pending Tasks: Scheduler queue is empty. Future Tasks: Maintenance 0 (10/28/2006 9:46:43 AM) Optimize KMailIndex Hold until 10/28/2006 9:56:43 AM Maintenance 0 (10/28/2006 9:46:43 AM) Optimize FileSystemIndex Hold until 10/28/2006 9:56:43 AM Maintenance 0 (10/28/2006 9:46:45 AM) Optimize GaimLogIndex Hold until 10/28/2006 9:56:45 AM Maintenance 0 (10/28/2006 9:46:45 AM) Optimize IndexingServiceIndex Hold until 10/28/2006 9:56:45 AM Maintenance 0 (10/28/2006 9:46:45 AM) Optimize TomboyIndex Hold until 10/28/2006 9:56:45 AM Maintenance 0 (10/28/2006 9:46:45 AM) Optimize BlamIndex Hold until 10/28/2006 9:56:45 AM Maintenance 0 (10/28/2006 9:46:45 AM) Optimize LifereaIndex Hold until 10/28/2006 9:56:45 AM Maintenance 0 (10/28/2006 9:46:45 AM) Optimize AkregatorIndex Hold until 10/28/2006 9:56:45 AM Maintenance 0 (10/28/2006 9:46:45 AM) Optimize KonqHistoryIndex Hold until 10/28/2006 9:56:45 AM Maintenance 0 (10/28/2006 9:46:46 AM) Optimize KopeteIndex Hold until 10/28/2006 9:56:46 AM but then shortly thereafter, this command no longer works, but simply hangs.
I am also seening the Xlib error when beagled hangs: Xlib: unexpected async reply (sequence 0x9)!
I also have the same problem, but for some reason Beagle indexes web pages for me.
(In reply to comment #7) > I am also seening the Xlib error when beagled hangs: > > Xlib: unexpected async reply (sequence 0x9)! > why does beagled use xlib?
I am also seeing this problem. beagle-status, fails after a few minutes but queries still work. After a longer period of time searches will also start failing.
I'm seeing problems with Beagle as well. I deleted the .Beagle directory and then forced an immediate index build. Able to search web and IM logs initial, but fails after short period of time.
(In reply to comment #11) > I'm seeing problems with Beagle as well. > > I deleted the .Beagle directory and then forced an immediate index build. Able > to search web and IM logs initial, but fails after short period of time. > that was the first thing I tryed same result
(In reply to comment #9) > (In reply to comment #7) > > I am also seening the Xlib error when beagled hangs: > > > > Xlib: unexpected async reply (sequence 0x9)! > > > > why does beagled use xlib? checking screensaver status si that it can tune to the load of the workstation.
Do you happen to be using the proprietary ATI driver? I've received a similar (although different) bug report against gkrellm on FC-6 which seems related to the use of the proprietary ATI driver.
I have the same problem and I'm using fglrx driver. I don't have much choice, having Radeon X1K series card..
(In reply to comment #14) > Do you happen to be using the proprietary ATI driver? Nope, same thing happens with the radeon driver from XOrg.
and with the i810 driver, too
yep, i810 here too, and I get the Xlib error (i945 integrated graphics)
I'm rather sure it's the screensaver checking code. hint 1: It does not crash if the DISPLAY enviuronment variable is *not* set. Quick fix: unset DISPLAY in the /usr/bin/beagled shell script hint2: setting MONO_EXTRA_ARGS environment variable to --trace=T:Beagle.Util.SystemInformation shows the following output: ENTER: Beagle.Util.SystemInformation:get_InputIdleTime ()() . ENTER: Beagle.Util.SystemInformation:CheckScreenSaver ()() . . ENTER: (wrapper managed-to-native) Beagle.Util.SystemInformation:screensaver_info (Beagle.Util.SystemInformation/ScreenSaverState*,Beagle.Util.SystemInformation/ScreenSaverKind*,ulong*,ulong*) (0xb68cec68, 0xb68cec64, 0xb68cec5c, 0xb68cec54, ) Xlib: unexpected async reply (sequence 0x9)!
The real problem is in the patch to the screensaver-glue.c file which tries to detect X Connection errors by reading X Events from the display in a glib IO callback. The callback is initialized in the main thread and therefore accesses the X display from the main thread. the screensaver information, which also accesses the X display is called from the Scheduler thread. This leads to a situation where two threads are reading X Events from the same X display, without locking and without a call to XInitThreads. Solution: Maybe the patch xconnection-exit is not necessary at all. the connection to the X display is checked everytime the screensaver_info function is called. Polling the display may make the process of detecting a broken X display connection faster, but being threadsafe is even much more overhead. Or simple register the g_io callback for G_IO_ERR and G_IO_HUP. Then the callback is only called when the X display lost it's connection (AFAIK, i may be wrong here).
unset DISPLAY isn't really a solution, because beagle will not be killed after logout or X restart.
without the xconnection-exit patch we were leaving beagle processes alive after logout, so that is certanly needed. A simple lock should solve the problem though, right?
Created attachment 140665 [details] Possible fix Anyone want to try this patch and see if it helps? (it replaces beagle-0.2.10-xconnection-exit.patch in the rpm)
(In reply to comment #23) > Created an attachment (id=140665) [edit] > Possible fix > > Anyone want to try this patch and see if it helps? > (it replaces beagle-0.2.10-xconnection-exit.patch in the rpm) Hi, I tested this patch over four hours and works fine for me. Beagle daemon don't hangs anymore. And no more "Xlib: unexpected async reply" when beagled is started from command line.
beagle-0.2.10-7.fc6 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
works fine here thx for the fix ;)
seems to work fine here too. Thanks :)