Bug 212370

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

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.