I ran evolution-exchange-storage 2.6.0 compiled with garnome 2.14.0
under valgrind. It uses evolution-data-server 1.6.0.

It complained once:
==1330== Invalid read of size 4
==1330==    at 0x4504B3C: open_async (e-cal.c:1850)
==1330==    by 0x552FC74: g_thread_create_proxy (gthread.c:582)
==1330==    by 0x4CF1A12: start_thread (in /lib/tls/libpthread.so.0)
==1330==    by 0x56309D9: clone (in /lib/tls/libc.so.6)
==1330==  Address 0x6471118 is 8 bytes inside a block of size 28 free'd
==1330==    at 0x401C14C: free (vg_replace_malloc.c:235)
==1330==    by 0x5517A1B: g_free (gmem.c:187)
==1330==    by 0x4504AD5: async_signal_idle_cb (e-cal.c:1837)
==1330==    by 0x5513E17: g_idle_dispatch (gmain.c:3796)
==1330==    by 0x5510489: g_main_dispatch (gmain.c:1916)
==1330==    by 0x55117EE: g_main_context_dispatch (gmain.c:2466)
==1330==    by 0x5511D0C: g_main_context_iterate (gmain.c:2547)
==1330==    by 0x55124C7: g_main_loop_run (gmain.c:2751)
==1330==    by 0x4C3B725: bonobo_main (bonobo-main.c:311)
==1330==    by 0x8078709: main (notify-main.c:162)

I haven't stepped through this in a debugger, but I suppose
that if the
  g_idle_add ((GSourceFunc) async_signal_idle_cb, ccad);
leads to an invocation of async_signal_idle_cb() before
open_async() returns, then the valgrind error is correct.
The obvious solution woould be to store the result before
in a local variable, invoking g_idle_add(), then return the
local variable.

This did not lead to a crash, but very well might under less
fortunate circumstances.