Re: Beagle 0.1.0 crash

2005-09-20 Thread Darren Davison
On Mon, 2005-09-19 at 17:24 -0400, Joe Shaw wrote:

 Someone else was seeing this too.  The most helpful thing would be if
 you could track this down to a specific backend, by using
 --allow-backend as an argument to beagled.  I'd suggest blowing away
 ~/.beagle each time so that you recreate a controlled environment each
 time.

It's the IMLog backend.  Details below.

I checked all the others individually to make sure there wasn't more
than one, but they're all OK.  However, I *did* see the same memory
issue as others have reported with the Files backend.  After running for
six hours, it was consuming 490Mb (VmRSS).  I didn't run the other
backends for long enough (or probably have enough content) to see if it
only applies to Files.

Regards,
Darren.




[EMAIL PROTECTED] ~ $ beagled --fg --debug --allow-backend IMLog
INFO: Starting Beagle Daemon (version 0.1.0)
DEBUG: Command Line: /usr/lib/beagle/BeagleDaemon.exe --fg --debug
--allow-backend IMLog

(beagled:25667): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
DEBUG: Starting main loop
DEBUG: Starting messaging server
DEBUG: Starting QueryDriver
DEBUG: Found index helper at /usr/lib/beagle/beagled-index-helper
DEBUG: Found 1 types in BeagleDaemonLib, Version=1.4.3.3,
Culture=neutral
DEBUG: Found 0 user-configured static queryables
DEBUG: Starting Scheduler thread
INFO: Starting Gaim log backend
inotify_init: Function not implemented
Inotify not supported!  You need a 2.6.13 kernel or later with
CONFIG_INOTIFY enabled.WARN: Could not initialize inotify
INFO: Gaim log backend worker thread done in .64s
DEBUG: Daemon initialization finished after 1.46s

Unhandled Exception: System.ArgumentNullException: null key
Parameter name: key
in [0x000c7] System.Collections.Hashtable:Find (System.Object key)
in [0x2]
(at 
/tmp/portage/mono-1.1.9/work/mono-1.1.9/mcs/class/corlib/System.Collections/Hashtable.cs:449)
 System.Collections.Hashtable:Contains (System.Object key)
in 0x003c9 Beagle.Util.Scheduler:Worker ()
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()

-- 
Darren Davison
Public Key: 0xDD356B0D


signature.asc
Description: This is a digitally signed message part
___
Dashboard-hackers mailing list
Dashboard-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/dashboard-hackers


Re: Beagle 0.1.0 crash

2005-09-20 Thread Joe Shaw
Hi,

On Tue, 2005-09-20 at 10:08 +0100, Darren Davison wrote:
 It's the IMLog backend.

Thanks a lot for tracking this down, I just checked in a fix for it into
CVS.  It is related to the fact that you're running without inotify.  If
you are building from source you can add the line:

task.Source = this;

inside the if (!Inotify.Enabled) brace, before the ThisScheduler.Add
(task); line in beagled/GaimLogQueryable/GaimLogQueryable.cs.

Joe

___
Dashboard-hackers mailing list
Dashboard-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/dashboard-hackers


Re: Beagle 0.1.0 crash

2005-09-19 Thread Joe Shaw
Hi,

On Mon, 2005-09-19 at 22:14 +0100, Darren Davison wrote:
 Hi guys, congrats on the 0.1.0 release!

Thanks!

 Now, I'm not yet running a 2.6.13 kernel, so have the wrong inotify version,
 but I'm not sure that's at fault here.  My understanding is that inotify won't
 affect the indexer much when it's starting from scratch.  I could be very
 wrong there, hence my post here and not bugzilla.

I don't think that'd affect this.

 Unhandled Exception: System.ArgumentNullException: null key
 Parameter name: key
 in [0x000c7] System.Collections.Hashtable:Find (System.Object key)
 in [0x2] (at
 /tmp/portage/mono-1.1.9/work/mono-1.1.9/mcs/class/corlib/System.Collections/Hashtable.cs:449)
 System.Collections.Hashtable:Contains (System.Object key)
 in 0x003c9 Beagle.Util.Scheduler:Worker ()
 in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()
 INFO: Kopete log backend worker thread done in 1.23s
 INFO: Gaim log backend worker thread done in 1.91s

Someone else was seeing this too.  The most helpful thing would be if
you could track this down to a specific backend, by using
--allow-backend as an argument to beagled.  I'd suggest blowing away
~/.beagle each time so that you recreate a controlled environment each
time.

Thanks,
Joe

___
Dashboard-hackers mailing list
Dashboard-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/dashboard-hackers