I managed to reproduce this again immediately. Then ran in valgrind to see if I could get any useful information (and didn't). And now can't reproduce at all, with or without valgrind.

Happened again today. I was adding a new appointment in a Google calendar. Wondered why it wasn't updating when I started typing the appointment summary, and it was because it'd crashed (sitting at gdb prompt). Will try to catch in valgrind...

(gdb) up 4

+ Trace 223860

$3 = 0x7fff853038c0
(gdb) p *book
$4 = {parent = {g_type_instance = {g_class = 0x1a3b360}, ref_count = 0, qdata = 0xaaaaaaaaaaaaaaaa}, priv = 0xaaaaaaaaaaaaaaaa}

wtf...

==28015== Invalid read of size 8
==28015==    at 0x74EE853: gdbus_book_closed_cb (e-book.c:117)
==28015==    by 0x3D3E6972E1: emit_signal_instance_in_idle_cb (gdbusconnection.c:3223)
==28015==    by 0x3D3D63EF22: g_main_context_dispatch (gmain.c:2119)
==28015==    by 0x3D3D63F6FF: g_main_context_iterate.clone.5 (gmain.c:2750)
==28015==    by 0x3D3D63FD71: g_main_loop_run (gmain.c:2958)
==28015==    by 0x3D3EF493C6: gtk_main (gtkmain.c:1219)
==28015==    by 0x4031E2: main (main.c:671)
==28015==  Address 0x1f2862a0 is 11 bytes after a block of size 5 alloc'd
==28015==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==28015==    by 0x3D3D645C80: g_malloc (gmem.c:134)
==28015==    by 0x3D3D65E31D: g_strdup (gstrfuncs.c:101)
==28015==    by 0x79EB077: camel_pstring_add (camel-string-utils.c:182)
==28015==    by 0x79BE40C: read_uids_flags_callback (camel-db.c:1105)
==28015==    by 0x35AEC5A1DE: sqlite3_exec (in /usr/lib64/libsqlite3.so.0.8.6)
==28015==    by 0x79BE5FC: camel_db_select (camel-db.c:963)
==28015==    by 0x79BEDE6: camel_db_get_folder_uids_flags (camel-db.c:1139)
==28015==    by 0x669CD19: camel_folder_summary_load_from_db (camel-folder-summary.c:1841)
==28015==    by 0x1A930D09: camel_imapx_summary_new (camel-imapx-summary.c:176)
==28015==    by 0x1A9344A8: camel_imapx_folder_new (camel-imapx-folder.c:70)
==28015==    by 0x1A934272: imapx_get_folder (camel-imapx-store.c:413)
==28015== 

That doesn't seem very useful.

It's actually gdbus_book_connection_gone_cb (which tail-calls into gdbus_book_closed_cb() which is why it doesn't show up in the trace). I managed to reproduce by killing e-addressbook-factory.

When e_book_dispose() is called, book->priv->gdbus_book is NULL. So the gone_signal doesn't get unsubscribed.

Created attachment 170894 [details] [review]
potential fix

It's being zeroed in gdbus_book_closed_cb(). That code should be disconnecting the signal etc., just as e_book_dispose() does. This patch moves it out into a gdbus_book_disconnect() function which is called from both places, and seems to fix the problem.

(I pondered just *not* zeroing it in gdbus_book_closed_cb() but I that didn't look right; various places check for book->priv->gdbus_book being NULL as an indication that it's disconnected and that operations will fail.)

Created attachment 170896 [details] [review]
fix same problem in e-cal.c

The same problem theoretically exists for ECal too; this fixes it there too. (Thanks mbarnes for pointing me at that).

It doesn't seem to happen in practice, because the disconnection signal handler only seems to get called once -- for EBook it was getting called a second time.

To ssh://dwmw2@git.gnome.org/git/evolution-data-server
   2b03f88..a728f5e  master -> master

Not closing bug; we need to push this to 2.32 too.

Review of attachment 170896 [details] [review]:

.

Review of attachment 170894 [details] [review]:

.

Created commit 55d0a4d in eds gnome-2-32 (2.32.1+)