Changed Severity to critical after reviewing severity definitions.

Further info: I have been able to reproduce the crash on 4 of 4 attempts with a
maildir created by Evolution rather than mutt. I did this as follows.

1. Create new maildir "Test1" under "Local maildirs", which is what I called my
local maildir account. (Right-click on folder pane -> New folder..., parent
"Local maildirs")
2. Copy a message from Inbox (under "On This Computer") to Test1. (Copy button,
select folder Test1 under "Local maildirs").
3. Exit and restart Evolution (crash did not occur without this step).
4. Select folder Test1 (click on Test1 in folder pane).
5. Delete message from Test1 (select message in message list pane, click delete
button).
6. Expunge Test1 (with Test1 still selected in folder pane, menu Actions ->
Expunge).
7. Delete Test1 (right-click on Test1 in folder pane -> Delete, confirm on
dialog box).
Result: Evolution crashed immediately after confirming delete. Test1 was not
deleted.

On one occasion when the crash occurred, a directory ".#evolution" was created
under my local maildirs directory, containing the files Junk.cmeta and
Trash.cmeta . This directory appears in the folder pane under "Local Maildirs".
I tried to delete it by right-click -> delete, but got an error dialog:
------8<------
Cannot delete folder ".#evolution".
Because "Cannot get folder `/home/davej/Maildirs/.#evolution': not a maildir
directory.".
------8<------

unique stack trace

Detailed version: evolution-2.2.2-5 FC4 stock binary RPM

I have subsequently had 4 other crashes that did not relate to deleting
maildirs, but the stack traces showed maildir-related functions leading to
g_assert_warning -> log -> abort -> raise, as in the stack trace above. Here are
the relevant excerpts from the traces for those crashes. (Crash 1 = the one
reported above).

=============================================================================
Crash 2
=============================================================================
Description of the crash:
Evolution crashed after I clicked the Send/Receive button while composing a
reply. The Send/Receive dialog appeared and the crash appeared while in the
process of retrieving POP messages. It may be relevant that in addition to the
POP account I have a local maildir account, so conceivably Evolution may have
been running a check on this rather than POP when it crashed.

Debugging Information:
Backtrace was generated from '/usr/bin/evolution'

+ Trace 61566

=============================================================================
Suggestions
=============================================================================
If this turns out to be FC4-specific, I wonder whether gcc4 or FORTIFY_SOURCE
might be relevant.

I'm experiencing similar crashes with Evolution reading offlineimap-produced
maildirs.  However, I needn't actually take any action to produce a crash --
Evolution will crash without me even touching keyboard or mouse, and doesn't
necessarily coincide with my settings for periodic scans of my maildir for
changes to its contents.

With Evolution 1.x on FC3, this didn't happen often.  With Evolution 2.0.x on
FC3, the problem was worse, and occurred several (5+) times a day.  Now I have
two separate computers using the stock evolution-2.2.2-5 RPM from FC4, and the
crash occurs _all the time_, ranging from immediately (milliseconds) after
starting Evolution (while it's beginning to scan my maildir), to anywhere from
2-30 minutes.  I haven't seen Evolution stay up for more than an hour or two --
this is extremely frustrating, as I need its Exchange connector at the office,
so would prefer to use it for email as well.


Possibly related to bug 268720?

I've filed bug 309320 to track my instance of this problem.  Hopefully, these
issues are one and the same.

Created attachment 48547 [details]
Stack trace of crash 1 (maildir expunge/delete) with debuginfo

Danial, that looks like a corrupt ibex file, try removing the *ibex* files for
the corresponding folder(s).

Dave, the other problems are also a corrupt ibex file, but they shouldn't all be
corrupt.

Are you using reiserfs by any chance?  What specific evolution version are you
using?

As a workaround, turn off indexing on the folder (menu click on the folder name
and select properties).

FWIW i can't recreate on 2.3.  It has another bug - when you subsequently select
another folder after deleting it you get a lot of references to the folder
object after it was finalised (only shows up in valgrind).

Dave, can you try valgrind perhaps?

On subsequent review of the valgrind stuff, it may be related afterall, e.g.
calling functions on a folder which has already been unreffed. valgrind output
would be handy to confirm.

Notzed,

Re: your Comment #7:
====================

Detailed version: evolution-2.2.2-5 FC4 stock binary RPM

I'm using ext3, not reiserfs.

Turning off indexing avoids "crash 1", i.e. the expunge/delete crash.

Three smaller problems presented while I was testing the above.
i) The first time I turned off indexing on local maildir Test1, after exiting
and restarting Evolution, indexing had been turned back on. I turned it off
again and subsequently it has remained off.
ii) After expunging and deleting Test1, when I click on another folder I get an
error dialog saying,
"Error while Storing folder 'Test1'.
Cannot open maildir directory path: /home/davej/Maildirs/Test1: No such file or
directory."
iii) I once accidentally tried to create local maildir Test1 when I had failed
to delete the preexisting Test1. The error dialog read as follows:
"Error while Creating folder `Test1'.
Cannot get folder: /home/davej/Maildirs///Test1: No such file or directory."
 - A surprising error message in this context. Note the triple slash. This
reminded me of your comment in Bug 303225:
"Usually problems like this are the backend creating inconsistent uri's and/or
not comparing them properly.  e.g. adding and/or not ignoring extra /'s, etc."
- Could this be relevant to the crashes?

Concerning crashes 2-5 (the ones that occured while checking mail or exiting),
should I submit a separate problem report for these? I could turn off indexing
on all maildirs (I have about 24) and see if any further crashes occur, or leave
indexing on and post further debug info, whichever would be more helpful.

Re: your Comment #9:
====================
I've never used valgrind. Can you let me know what options I need to use? I've
found:
http://valgrind.org/docs/quick-start.html
Is Memcheck the tool I should be using?

Thanks,
Dave

I have reproduced Crash 1 (expunge/delete) using valgrind with no options
specified. Apart from a slew of errors in libORBit, libsoftokn3 and libX11, all
I get is this:
"camel-ERROR **: file camel-partition-table.c: line 836
(camel_key_table_set_flags): assertion failed: (index < kb->used)"
 - which is the same info as contained in the previously attached "Stack trace
of crash 1 (maildir expunge/delete) with debuginfo".

I had another crash on exit. I had just created maildir Test1, copied a message
to it and clicked the WM's close button. Bugbuddy produced a stack trace, but it
seems to be truncated. I'll attach it in case there's anything useful. I then
restarted Evolution with valgrind and got the following output at startup:

(evolution:3515): camel-WARNING **: Invalid root:
'/home/davej/Maildirs/Test1.ibex.index'
(evolution:3515): camel-WARNING **: version: TEXT.000 (TEXT.000)
(evolution:3515): camel-WARNING **: block size: 1024 (1024) OK
(evolution:3515): camel-WARNING **: free: 0 (0 add size < 14336) OK
(evolution:3515): camel-WARNING **: last: 7168 (7168 and size: 14336) BAD
(evolution:3515): camel-WARNING **: flags: unSYNC

Created attachment 48688 [details]
Stack trace of crash on exit with debuginfo -truncated by buggy bugbuddy

Sadly truncated at a crucial point in Thread 2 by Bugbuddy.

Created attachment 48690 [details]
gdb session stepping through expunge/delete crash

I haven't used gdb for years, but hope this is of some use. Crash occurs at:
g_assert(index < kb->used)
where index and kb->used are both zero.

the assert already provides enough info there - which isn't much.

since you have gdb up, can you go up to a frame which has a folder in it (like
camel_folder_sync) and print the folder?

p *folder
& also
p *((CamelObject *)folder).klass
(should print the folder's class which should be maildir but just checking).

valgrind may prove more useful too, run evolution with valgrind --num-callers=24
--alignment=8

Thanks for the response. Here's gdb output as requested. I put a breakpoint at
camel_key_table_set_flags, checked that I was in the call where the assert was
about to fail and went up to the camel_folder_sync frame.

(gdb) f 10

+ Trace 61599

$12 = {parent_object = {klass = 0x9443b08, magic = 2007188717,
    hooks = 0x94987b0, ref_count = 3, flags = 0, next = 0x94a0188,
    prev = 0x94a00c0}, priv = 0x94e54d8, name = 0x94ff7a8 "Test1",
  full_name = 0x94ff7b8 "Test1", description = 0x0, parent_store = 0x93eaa20,
  summary = 0x94b8d5c, folder_flags = 3, permanent_flags = 2147483743}
(gdb) p *((CamelObject *)folder).klass
$13 = {parent = 0x93ca4d0, magic = 3995511191, next = 0x93ca5f0, child = 0x0,
  name = 0x5e74dfa "CamelMaildirFolder", lock = 0x9443bf0, object_size = 100,
  klass_size = 228, hooks = 0x93f0fcc, instance_chunks = 0x9443c10,
  instances = 0x959a648,
  klass_init = 0x5e6eb87 <camel_maildir_folder_class_init>,
  klass_finalise = 0, init = 0x5e6ec04 <maildir_init>,
  finalise = 0x5e6ec09 <maildir_finalize>, setv = 0x5e65180 <local_setv>,
  getv = 0x5e6eaa4 <maildir_folder_getv>, free = 0x7f4c3f <folder_free>,
  meta_get = 0x4fe04c <cobject_meta_get>,
  meta_set = 0x4fdea8 <cobject_meta_set>,
  state_read = 0x500831 <cobject_state_read>,
  state_write = 0x4ff10e <cobject_state_write>}

valgrind hasn't produced anything useful, --num-callers=24 didn't help as it
doesn't find any errors anyway (apart from libORBit, libsoftokn3 & libX11 as
mentioned in Comment #11) and --alignment=8 appears to be the default in my
installation.

hmm, refcount is 3, i had 0, hmm.  so its not the same issue anyway.

i dont know what to suggest, get a newer 2.2 if on exists - i tried on the 2.2 i
have here and it didn't fail.

I've just tried to reproduce the problem with a new user account and pristine
Evolution settings, without my old Mutt maildirs, and couldn't, even after
creating 10 local maildirs from the UI. So maybe it's something to do with the
quantity - I have 79MB of mail in 23 maildirs - or specific content of those
Mutt maildirs, even though the problem occurs when
creating/populating/emptying/expunging/deleting a new maildir from the UI.

While testing on the pristine account, I noticed that when copying a message,
the "Select folder" popup remembers the last folder copied to, highlighting it
as the initial selection. This does not happen with my account. I believe it did
initially, but has not done so for some time. Might this provide a clue about
what's going wrong?

Oh, now I've just got a load of odd messages:
(evolution:4009): camel-WARNING **: Could not find key entry for word 'is':
Invalid argument
(evolution:4009): camel-WARNING **: Could not find key entry for word 'adds':
Invalid argument
(evolution:4009): camel-WARNING **: Could not find key entry for word 'mailman':
Invalid argument
(evolution:4009): camel-WARNING **: Could not find key entry for word 'menu':
Invalid argument
(evolution:4009): camel-WARNING **: Could not find key entry for word 'f1':
Invalid argument
...and many more like it. They appear to be words from the Evolution welcome
email, which was the mail I used to check about remembering folder on copy.

Just got these two sets of errors when selecting my Test1 folder on the folder
pane. I selected various other folders in between, none of which produced
errors. I did not change any folder; Test1 was just sitting there with a single
message in it.

(evolution:4009): camel-WARNING **: Invalid root:
'/home/davej/Maildirs/Test1.ibex.index'
(evolution:4009): camel-WARNING **: version: TEXT.000 (TEXT.000)
(evolution:4009): camel-WARNING **: block size: 1024 (1024) OK
(evolution:4009): camel-WARNING **: free: 0 (0 add size < 10240) OK
(evolution:4009): camel-WARNING **: last: 7168 (7168 and size: 10240) BAD
(evolution:4009): camel-WARNING **: flags: unSYNC
update flow align
...
(evolution:4009): camel-WARNING **: Invalid root:
'/home/davej/Maildirs/Test1.ibex.index'
(evolution:4009): camel-WARNING **: version: TEXT.000 (TEXT.000)
(evolution:4009): camel-WARNING **: block size: 1024 (1024) OK
(evolution:4009): camel-WARNING **: free: 0 (0 add size < 10240) OK
(evolution:4009): camel-WARNING **: last: 8192 (8192 and size: 10240) BAD
(evolution:4009): camel-WARNING **: flags: SYNC

Another apparently maildir-related crash: this one happened during Send/Receive,
while running evolution through gdb: output follows.

----8<----
Program received signal SIGSEGV, Segmentation fault.

+ Trace 61633

(gdb) p *folder
$5 = {parent_object = {klass = 0xb67009d0, magic = 2007188717,
    hooks = 0xb67bbb48, ref_count = 3, flags = 0, next = 0xb6785d28,
    prev = 0xb6785c60}, priv = 0xb67b5ec0, name = 0xb67b52f8 "Personal",
  full_name = 0xb67b5308 "Personal", description = 0x0,
  parent_store = 0x9868b60, summary = 0xb678826c, folder_flags = 3,
  permanent_flags = 2147483743}

(gdb) p (CamelLocalSummary *)folder->summary
$6 = (struct _CamelLocalSummary *) 0xb678826c
(gdb) p *(CamelLocalSummary *)folder->summary
$7 = {parent = {parent = {klass = 0xb6702ce8, magic = 2007188717, hooks = 0x0,
      ref_count = 1, flags = 0, next = 0xb67882e0, prev = 0xb67881f8},
    priv = 0xb67bd450, version = 13, flags = 0, nextuid = 1, time = 0,
    saved_count = 534, unread_count = 0, deleted_count = 1, junk_count = 0,
    message_info_size = 76, content_info_size = 32,
    message_info_chunks = 0xb67c0548, content_info_chunks = 0x0,
    summary_path = 0xb67bd5d0 "/home/davej/Maildirs/Personal.ev-summary",
    build_content = 0, messages = 0xb678dc38, messages_uid = 0xb67bd4e0,
    folder = 0xb6785cc4}, version = 1,
  folder_path = 0xb67bd600 "/home/davej/Maildirs/Personal",
  index = 0xb67a20e0, index_force = 0, check_force = 0}
----8<----

Created attachment 48861 [details]
Valgrind output

Valgrind output from a run where I checked mail, then emptied, expunged &
deleted a maildir. Not sure if there's anything useful here, errors relate to
libORBit, libsoftokn, libX11, libssl.

those are unrelated to maildir specifically.  turn off 'body indexing' on the
given folder i guess.

lowering pri due to lack of duplicates & unable to reproduce.

This could be a clue. I re-tried removing all the *.ibex.* files, then started
evolution from the command line so that I could see any warnings. This is what I
got:

(evolution:2813): e-data-server-WARNING **: Could not open converter for
'unicode-1-1-utf-7' to 'UTF-8' charset
(evolution:2813): camel-WARNING **: Cannot create charset conversion from
unicode-1-1-utf-7 to UTF-8: Invalid argument
(evolution:2813): camel-WARNING **: Cannot convert 'unicode-1-1-utf-7' to
'UTF-8', message index may be corrupt
(evolution:2813): camel-WARNING **: Cannot create charset conversion from
unicode-1-1-utf-7 to UTF-8: No such file or directory
(evolution:2813): camel-WARNING **: Cannot convert 'unicode-1-1-utf-7' to
'UTF-8', message index may be corrupt
(evolution:2813): camel-WARNING **: Cannot create charset conversion from
unicode-1-1-utf-7 to UTF-8: No such file or directory
(evolution:2813): camel-WARNING **: Cannot convert 'unicode-1-1-utf-7' to
'UTF-8', message index may be corrupt

Fedora Core 4 uses UTF-8 by default. Would these messages indicate that there
are three specific folders, or three specific messages, which are causing problems?

After removing the *.ibex.* files, I was able to reproduce the
empty/expunge/delete crash (Crash 1) at first attempt.

Dave

those warnings are all pretty harmless - they just point to messages with
made-up (i.e. unusable) charset specifiers.

i guess your'e still getting the assertion failure in camel?

any chance of a run in valgrind, after removing the ibex files?

the indexing problem is a long-standing one, if you have the time to do the
above it might help track it down, because it has never been reproducible at all.

i hate to be able to offer no fix after all this effort :(

Re comment #25
Thanks for the response. I did a valgrind run after deleting all the ibex files
and we may have something interesting. In addition to the libORBit, libsoftokn3
and libX11 errors found previously, I got this:

==2734== Thread 3:
==2734== Conditional jump or move depends on uninitialised value(s)
==2734==    at 0x34F5205: (within /usr/lib/libcamel-1.2.so.0.0.0)
==2734==    by 0x34D3645: camel_index_name_add_buffer (in
/usr/lib/libcamel-1.2.so.0.0.0)
==2734==    by 0x34D95F2: (within /usr/lib/libcamel-1.2.so.0.0.0)
==2734==    by 0x34DB8E9: (within /usr/lib/libcamel-1.2.so.0.0.0)
==2734==    by 0x34DEDFC: (within /usr/lib/libcamel-1.2.so.0.0.0)
==2734==    by 0x34DF0BB: camel_mime_parser_step (in /usr/lib/libcamel-1.2.so.0.0.0)
==2734==    by 0x1BEE0B9E: ??? (camel-folder-summary.c:2013)
==2734==    by 0x1BEE1027: camel_folder_summary_info_new_from_parser
(camel-folder-summary.c:914)
==2734==    by 0x1BEE10ED: camel_folder_summary_add_from_parser
(camel-folder-summary.c:822)
==2734==    by 0x1C36B11F: ??? (camel-maildir-summary.c:488)
==2734==    by 0x1C36B77B: ??? (camel-maildir-summary.c:609)
==2734==    by 0x1C360B24: camel_local_summary_check (camel-local-summary.c:265)
==2734==    by 0x1C36B8A6: ??? (camel-maildir-summary.c:738)
==2734==    by 0x1C360B75: camel_local_summary_sync (camel-local-summary.c:294)
==2734==    by 0x1C35E9B1: camel_local_folder_construct (camel-local-folder.c:296)
==2734==    by 0x1C368CF0: camel_maildir_folder_new (camel-maildir-folder.c:148)
==2734==    by 0x1C36971E: ??? (camel-maildir-store.c:193)
==2734==    by 0x1BEFA031: camel_store_get_folder (camel-store.c:258)
==2734==    by 0x1C36A0B6: ??? (camel-maildir-store.c:305)
==2734==    by 0x1C36A642: ??? (camel-maildir-store.c:468)
==2734==    by 0x1C36A804: ??? (camel-maildir-store.c:512)
==2734==    by 0x1BEFAF88: camel_store_get_folder_info (camel-store.c:774)
==2734==    by 0x1C090B54: ??? (em-folder-tree.c:1765)
==2734==    by 0x1C0BF0E8: ??? (mail-mt.c:556)
==2734== 

I have kept the full valgrind output but the above is the only error reported in
libcamel.

Dave

ooh, interesting.  at least it narrows it down to 1 function.  but the data is
really the thing :-/

you could try using --gdb-attach=yes so valgrind runs gdb as soon as it detects
the problem, then with debugging packages you can do 'info locals' (or 'bt full'
to get all stack frames), to get some details of the data it is failing on.

the problem is it will attach on all the other unteresting things too.  valgrind
can suppress certain things, maybe you can use --gen-suppressions=yes to get a
surpression file for it (never used it, so i dont know if it will work or how
you use it).

I tried valgrind with --db-attach=yes, but even though I have the following
debug packages...

evolution-debuginfo-2.2.2-5
evolution-data-server-debuginfo-1.2.2-3
glibc-debuginfo-2.3.5-10
glibc-debuginfo-common-2.3.5-10

...I get...

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

Attaching to program: /proc/6485/fd/1015, process 6485
0x034f5205 in ?? ()
(gdb) bt

+ Trace 62362

No symbol table info available.

'bt full' gives 'No symbol table info available.' for each frame. Are there
other debug packages I need?

ho hum, no, that should suffice.

for some of the earlier hits you probably wont get much in the bt, but that
looks like the frame pointer is nowhere useful, i guess you could try to isolate
that one hit, but you might just be wasting your time.

Another tack, the folder containing this message:

"1120904246.2924_1.bagpuss.localdomain:2,S",

if you remove just its ibex file, does it still crash?

and if so, how big is that folder/is it public info/etc?

(nice hostname)

Further developments: an updated evolution-data-server package has just been
released for FC4, details here:

https://www.redhat.com/archives/fedora-test-list/2005-August/msg00073.html

I installed this and the corresponding debuginfo package:
evolution-data-server-1.2.3-2.fc4
evolution-data-server-debuginfo-1.2.3-2.fc4

Results with updated evolution-data-server
------------------------------------------
(a) So far after 3 or 4 attempts to replicate the empty/expunge/delete crash, it
has not occurred. Previously it occurred 100% of the time. I'll test further,
but perhaps we'll need to rename or split this problem report?

(b) When copying a message, the previously chosen folder is now selected in the
destination folder list; this was failing previously, as described in comment #18.

(c) After deleting all ibex files and running through valgrind, the camel error
still occurs. This time there is more info in the valgrind trace, below; however
gdb still does not find any symbol table info.

--------8<--------
==3105== Thread 2:
==3105== Conditional jump or move depends on uninitialised value(s)
==3105==    at 0x1BB4B225: ??? (camel-text-index.c:1453)
==3105==    by 0x1BB29645: camel_index_name_add_buffer (camel-index.c:327)
==3105==    by 0x1BB2F5F2: ??? (camel-mime-filter-index.c:67)
==3105==    by 0x1BB318E9: ??? (camel-mime-filter.c:187)
==3105==    by 0x1BB34DFC: ??? (camel-mime-parser.c:1686)
==3105==    by 0x1BB350BB: camel_mime_parser_step (camel-mime-parser.c:627)
==3105==    by 0x1C109B9E: ??? (camel-folder-summary.c:2013)
==3105==    by 0x1C10A027: camel_folder_summary_info_new_from_parser
(camel-folder-summary.c:914)
==3105==    by 0x1C10A0ED: camel_folder_summary_add_from_parser
(camel-folder-summary.c:822)
==3105==    by 0x1C59413F: ??? (camel-maildir-summary.c:488)
==3105==    by 0x1C59479B: ??? (camel-maildir-summary.c:609)
==3105==    by 0x1C589B24: camel_local_summary_check
(camel-local-summary.c:265)==3105==    by 0x1C5948C6: ???
(camel-maildir-summary.c:738)
==3105==    by 0x1C589B75: camel_local_summary_sync (camel-local-summary.c:294)
==3105==    by 0x1C5879B1: camel_local_folder_construct (camel-local-folder.c:296)
==3105==    by 0x1C591D10: camel_maildir_folder_new
(camel-maildir-folder.c:148)==3105==    by 0x1C59273E: ???
(camel-maildir-store.c:193)
==3105==    by 0x1C123031: camel_store_get_folder (camel-store.c:258)
==3105==    by 0x1C5930D6: ??? (camel-maildir-store.c:305)
==3105==    by 0x1C593662: ??? (camel-maildir-store.c:468)
==3105==    by 0x1C593824: ??? (camel-maildir-store.c:512)
==3105==    by 0x1C123F88: camel_store_get_folder_info (camel-store.c:774)
==3105==    by 0x1C2EB590: ??? (mail-ops.c:1065)
==3105==    by 0x1C2E80E8: ??? (mail-mt.c:556)
==3105==
--------8<--------

Re comment #29:
---------------
I'm not sure what you mean by "you could try to isolate that one hit", if you
think this is worth pursuing, could you elaborate?

The message that you mention is in a folder of personal correspondence, of size 12M.

http://www.smallfilms.co.uk/bagpuss/

one hit, i meant the valgrind 'hit' of interest, vs the others.  maybe you were
doing that already.

well, at least this one has line numbers - but that line can't possibly be
accessing an unset value!  it is a variable on the stack it is checking ...

1453:	if (buffer == NULL) {
		if (p->buffer->len) {

Unless it is just one off on 1454 (optimisation may mess it up i guess), but
that can't be unset either, unless the index object was finalised, which would
cause more problems.

Since the crash is fixed now, just leave it to me for a while, i'm going to have
to trace through all that code in the right version, and try to work out why it
might've stopped crashing as well (nothing obvious!  there are only 2 minor and
unrelated changes between 1.2.2 and 1.2.3 in all of camel).  Maybe it's just a
wild goosechase ...

If the bug is split, what is the other bug?  Oh and that message, there's
nothing unusual about it i presume, just plain simple us-ascii text?  no funny
binary characters in it?

after running valgrind for hours i've managed to reproduce this, so i can take
it from here.  it only happens with maildir it seems.

i also found some other bugs in the parser already too, see bug 313284.

thanks for your help.

Re comment #31

When I mentioned splitting or renaming the bug report, I was thinking that there
are 3 issues here:
(i) My "crash 1" - the empty/expunge/delete crash, which for me was 100%
reproducible.
(ii) My crashes 2 to 5 - sporadic crashes during send/receive or shutdown, which
happened perhaps twice a day.
(iii) The error reported by valgrind after removing ibex files.

As I reported, evolution-data-server-1.2.3-2.fc4 fixed (i). The next day,
evolution-2.2.3-2.fc4 was released. Since installing these packages I have not
had any instances of (ii), I'm happy to say!

I have not investigated (iii) any further as you seem to be on the case. The
message that you asked about is indeed plain text, no odd characters, no
attachments. I don't think that message was the issue; the problem was happening
a few weeks before I received it. I'd guess it's just the message that happened
to be being processed when some pre-existing corruption happened to bite.

Thanks for all your efforts and good luck with the detective work!

Dave

reassigning stuff that has been assigned to notzed. goodbye, dude. :-/

also see bug 348149

Hi Dave, can you recheck with recent Evolution (2.22.2) please? It seems like the initial issue was really fixed, and regarding to other issues, I'm kinda lost in such long bug, so maybe you will know better. Thanks in advance.

As whole design has been changed in 2.24.0 how we handle message on disk due to camel db changes, better to try in current stable (2.24.x or later). 

Please feel free to reopen the bug if the problem still occurs with a newer
version of GNOME 2.24.0, thanks.