Sorry for the lack of context.  This has started happening regularly after upgrading to 2.30 on debian.  It generally happens within about 5 minutes of sitting idly.

Line 243 is a strange place for it to crash.  It implies the backend is either finalized or there's something wrong with the private pointer.

239: static void
240: mail_shell_backend_sync_store_cb (CamelStore *store,
241:                                   EMailShellBackend *mail_shell_backend)
242: {
243:         mail_shell_backend->priv->mail_sync_in_progress++;
244:
245:         mail_sync_store (
246:                 store, FALSE,
247:                 mail_shell_backend_sync_store_done_cb,
248:                 mail_shell_backend);
249: }

Debian's packaging of Evolution 2.30 has been particularly problematic for some reason; much more so than on Fedora.  It looks like they may have enabled large file support in Camel, which is breaking existing accounts in strange and mysterious ways.  But I don't yet know if that has anything to do with this bug.

Would you mind trying to reproduce this crash in a gdb session and then examining the contents of "mail_shell_backend" and "mail_shell_backend->priv" so I can see exactly what it's dying on?

(gdb) p *mail_shell_backend
$2 = {parent = {parent = {parent = {g_type_instance = {
          g_class = 0x6e6f6874616e6f6a}, ref_count = 1852795438, 
        qdata = 0x6f62616c6c6f6340}, priv = 0x6b752e6f632e6172}, priv = 0x0}, 
  priv = 0x25}


something strange certainly going on there.

Hopefully-useful valgrind info:

==26083== Thread 1:
==26083== Invalid read of size 8
==26083==    at 0x1828ECE0: mail_shell_backend_sync_store_cb (e-mail-shell-backend.c:243)
==26083==    by 0x1890763B: e_mail_store_foreach (e-mail-store.c:429)
==26083==    by 0x1828ECCE: mail_shell_backend_mail_sync (e-mail-shell-backend.c:268)
==26083==    by 0xE1B0E9A: g_timeout_dispatch (gmain.c:3396)
==26083==    by 0xE1B06C1: g_main_context_dispatch (gmain.c:1960)
==26083==    by 0xE1B4537: g_main_context_iterate (gmain.c:2591)
==26083==    by 0xE1B4A44: g_main_loop_run (gmain.c:2799)
==26083==    by 0xB848646: gtk_main (gtkmain.c:1219)
==26083==    by 0x4027D3: main (main.c:578)
==26083==  Address 0x1a438fb8 is 7 bytes after a block of size 33 alloc'd
==26083==    at 0x4C221A7: malloc (vg_replace_malloc.c:195)
==26083==    by 0xE1B9504: g_malloc (gmem.c:132)
==26083==    by 0xE1D0D7D: g_strdup (gstrfuncs.c:102)
==26083==    by 0x1890796C: mail_store_add (e-mail-store.c:86)
==26083==    by 0x18907BFD: e_mail_store_add_by_uri (e-mail-store.c:330)
==26083==    by 0x18907EDE: e_mail_store_init (e-mail-store.c:260)
==26083==    by 0x1828ED3B: mail_shell_backend_constructed (e-mail-shell-backend.c:484)
==26083==    by 0xD92F8F7: g_object_newv (gobject.c:1289)
==26083==    by 0xD93014C: g_object_new_valist (gobject.c:1377)
==26083==    by 0xD930390: g_object_new (gobject.c:1095)
==26083==    by 0x4E400FD: shell_add_backend (e-shell.c:413)
==26083==    by 0x71055F9: e_type_traverse (e-util.c:514)
==26083== 
==26083== Invalid read of size 4
==26083==    at 0x1828ECF0: mail_shell_backend_sync_store_cb (e-mail-shell-backend.c:243)
==26083==    by 0x1890763B: e_mail_store_foreach (e-mail-store.c:429)
==26083==    by 0x1828ECCE: mail_shell_backend_mail_sync (e-mail-shell-backend.c:268)
==26083==    by 0xE1B0E9A: g_timeout_dispatch (gmain.c:3396)
==26083==    by 0xE1B06C1: g_main_context_dispatch (gmain.c:1960)
==26083==    by 0xE1B4537: g_main_context_iterate (gmain.c:2591)
==26083==    by 0xE1B4A44: g_main_loop_run (gmain.c:2799)
==26083==    by 0xB848646: gtk_main (gtkmain.c:1219)
==26083==    by 0x4027D3: main (main.c:578)
==26083==  Address 0x1a43a0a8 is not stack'd, malloc'd or (recently) free'd
==26083== 
==26083== 
==26083== Process terminating with default action of signal 11 (SIGSEGV)
==26083==  Access not within mapped region at address 0x3FF0021
==26083==    at 0x1828ECF0: mail_shell_backend_sync_store_cb (e-mail-shell-backend.c:243)
==26083==    by 0x1890763B: e_mail_store_foreach (e-mail-store.c:429)
==26083==    by 0x1828ECCE: mail_shell_backend_mail_sync (e-mail-shell-backend.c:268)
==26083==    by 0xE1B0E9A: g_timeout_dispatch (gmain.c:3396)
==26083==    by 0xE1B06C1: g_main_context_dispatch (gmain.c:1960)
==26083==    by 0xE1B4537: g_main_context_iterate (gmain.c:2591)
==26083==    by 0xE1B4A44: g_main_loop_run (gmain.c:2799)
==26083==    by 0xB848646: gtk_main (gtkmain.c:1219)
==26083==    by 0x4027D3: main (main.c:578)

I think we agreed on IRC that this might be due to an ABI mismatch in Debian's packaging because the stack trace is so out of whack.  Have you seen this crash again?

well, I downgraded to 2.28 for a while because of this.  I've now just upgraded again, and I see it every time I try to start evolution.  I will try to report a bug downstream in debian.

for reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585921

Hey, Debian packager here.

What exactly are you calling “abi mismatch”? We had problem which were related to largefile handling, but I don't see how disabling it would be  a solution (except if you're saying it's serverly broken and shouldn't be used at all, which might be problematic, afaik).

I mean, I can disable largefile support if it's not stable, but that still looks like a bad workaround. If largefile support is broken, it should be fixed.

Yves-Alexis: the ABI mismatch we're talking about is just speculation.  If you look at the trace (and particularly comment #3), you'll notice that the mail_shell_backend->priv has a value of 0x25, which is clearly garbage.  So the two possibilities I can think of are: A) that value is being corrupted, or B) different parts of the code have different ideas about the struct layout (e.g. ABI mismatch) such that it tries to read ->priv from a section of the memory that is not within the struct boundary.  

The valgrind trace indicates that option A) is not likely since the invalid read was from an address that was "not stack'd, malloc'd or (recently) free'd".  So that leaves us assuming option B: an ABI mismatch somewhere.

(In reply to comment #10)
> Yves-Alexis: the ABI mismatch we're talking about is just speculation.  If you
> look at the trace (and particularly comment #3), you'll notice that the
> mail_shell_backend->priv has a value of 0x25, which is clearly garbage.  So the
> two possibilities I can think of are: A) that value is being corrupted, or B)
> different parts of the code have different ideas about the struct layout (e.g.
> ABI mismatch) such that it tries to read ->priv from a section of the memory
> that is not within the struct boundary.  
> 
> The valgrind trace indicates that option A) is not likely since the invalid
> read was from an address that was "not stack'd, malloc'd or (recently) free'd".
>  So that leaves us assuming option B: an ABI mismatch somewhere.

Yeah, it might make sense, I was just saying that if it's related to largefile, we shouldn't hide the problem but try to fix it.

Jonathon found the real problem: callback function had the wrong signature.

Fixed on master and gnome-2-30 branches (just in time for 2.30.2!):

http://git.gnome.org/browse/evolution/commit/?id=524a26232bf4028f59880a6636b938d60a3227d9

http://git.gnome.org/browse/evolution/commit/?h=gnome-2-30&id=53f8bd8e6e963b866efb2e5536f28a116f1912c4

excellent.  I've rebuilt the debian package with this patch attached and it fixes the issue for me.  thanks.

(In reply to comment #13)
> excellent.  I've rebuilt the debian package with this patch attached and it
> fixes the issue for me.  thanks.

Good to know, thank your for checking. Expect evolution packages next week in unstable (if everything goes fine :)