Known Issues

Here are listed the known issues for all the releases (mostly from 0.3.0) and their corresponding fixes.

version 0.3.7

beagle-search does not start in recent KDE3

Problem: Recent beagle-search does not start in KDE-3. When started from a terminal, it will crash saying System.Exception: Unable to open the session message bus.. This only happens in some distributions.

Workaround: Make sure session dbus is running. You can check by verifying that echo $DBUS_SESSION_BUS_ADDRESS is non-empty. If your distribution has stopped starting session dbus in KDE-3, you can use a tip from http://gentoo-wiki.com/TIP_D-BUS_Session_Bus_with_KDM:

Simply create the following file and give yourself read and execute permissions. (the ~/.kde/env directory probably won't exist. Just create it.)

File: ~/.kde/env/start_dbus_session_bus.sh

 # test for an existing bus daemon, just to be safe
 if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
      # if not found, launch a new one
      eval `dbus-launch --sh-syntax --exit-with-session`
 fi

All you need to do now is log out. The session bus will now start every time you log in, and exit when you log out.

Explanation: Earlier Xsession used to start the session dbus at login. Most likely some kind of Xsession.d script. Some distributions recently dropped the file. Recent beagle-search requires session dbus to be running (not the fake kind priovided by dbus-launch but a real session dbus). This is not a problem in Gnome since it starts dbus at login (this is what I have been told). Apparently Xfce and some others do that too. But KDE-3 does not. This makes it impossible to run beagle-search in recent KDE-3.

version 0.3.x - 0.3.6.1

beagle-search, gtkfilechooser hangs; beagled does not respond and refuses to be killed

Problem: For some users using the evolution-data-server backend, beagled might stop responding. This will cause beagle-search and other apps talking to beagle like gtkfilechooser or nautilus to also hang. The obvious symptom is 'begale-ping' will not return. beagled can only be killed with kill -9.

Bugs:

(beagle) 

http://bugzilla.gnome.org/show_bug.cgi?id=529262 depends on

(evolution-sharp) 

http://bugzilla.gnome.org/show_bug.cgi?id=519284

(mono) 

https://bugzilla.novell.com/show_bug.cgi?id=381928

Workaround: Disable the evolution-data-server backend till the evolution-sharp bug is fixed.

Explanation: See the bug reports for details. In short, a C library of evolution-sharp crashes. This would generally result in beagled crashing and aborting which is bad but at least won't hang programs trying to connect to beagled. However, mono tries to print a debug stacktrace when beagled crashes and then itself hangs.

There is a workaround to this problem in beagle 0.3.7 and mono was fixed for 1.9.2.

version 0.3.3

sidebar does not work in firefox-extension in 0.3.3

Problem: The firefox-extension in beagle 0.3.3 is supposed to include a sidebar. But the sidebar does not open, instead firefox complains it is unable to find sidebar.xul.

Fix: Use the modified extension from http://beagle-project.org/files/0.3/beagle.xpi

Explanation: The sidebar related files were not added to the Makfile target. The problem has been corrected in the svn trunk (r4461).

version 0.3.0

beagle-0.3.0 crashes at start

For beagle-0.3.0, beagled crashes when started. The stacktraces look like (once for each backend):

Fix: Stop beagled, delete ~/.beagle/TextCache directory and start beagled. Also, r4251 fixes the problem.

Explanation: The format of all data stored in ~/.beagle changed from 0.2.x to 0.3.0. It was ensured that all the different kinds of old data were purged or upgraded to the new format. Unfortunately, this check was missed for the TextCache.db textcache data. As a result, users who were using beagle-0.2.x with sqlite3 will see beagled crashing when trying to start the backends.

This will not happen for users running sqlite2 earlier, since their database will be automatically deleted. Since almost all of beagle-0.2.x data is incompatible with beagle-0.3.0, all of them are anyway deleted when beagled is started; except config files, which are modified according to the new format. If there are no config files in ~/.beagle/config, deleting ~/.beagle will not cause any additional loss of data.

beagle-0.3.0 goes into a loop while indexing certain HTML emails

For some HTML emails, the index-helper will cause 100% CPU for a long time and might end up using a lot of memory. This can happen for emails from any of the email backends or for email files in the file system. Saving these email on the disk and running beagle-extract-content --mimetype=message/rfc822 /path/to/saved/email will reproduce the problem.

Fix: Use the patch r4262. It a temporary workaround. The final fix is being discussed in http://bugzilla.gnome.org/show_bug.cgi?id=501803 (see the attached patch in this bug for the likely final fix).

Explanation: Earlier the email filter used to treat all non-text message parts as attachments, save them to temporary files on the disk and index them as attachments. The email filter was slightly modified in 0.3.0 to treat HTML message parts also as message body (with the side effect of not having to create a temporary file). A problem was detected in how the HTML filter that parses the HTML message part, uses the GMime.Stream for that message part. See gnome-bug #501803 for the detailed explanation). The workaround stores that message part in a memorystream and gives it to the HTML filter. The memorystream behaves similar to a filestream and so there should be no problem.

version 0.2.18+

EvolutionDataServer backend leaks memory

Problem: Since 0.2.18 (including 0.3.x releases), beagled could be leaking memory when the EvolutionDataServer backend is enabled.

The problem has been observed when there are one or more webcal calender items in Evolution. It is not immediately clear, but the memory leak might be present even otherwise. The memory is leaked when there is new data to index in Evolution; webcal sources with the default 30 min sync rate will show the memory RSS jumping roughly every 30 minutes.

Workaround: Disable the EvolutionDataServer backend, or as a less severe workaround set the sync interval for the webcal calender to something large.

Explanation: The memory leak is present in evolution-sharp and is probably in a couple of new methods introduced in a recent evolution-sharp. Visit http://bugzilla.gnome.org/show_bug.cgi?id=509536 for details on the evolution-sharp bug.