Even after fixes in bug #578287 there are still used places which valgrind claims about. Claims are about invalid reads, reading of already freed memory and some leaks. See the clean-up patch attached below.

Few things:
a) the update of summary folder hashes, is it possible to have storing different values? As there was used memory given from the hash itself, then I added there only checking for already known values. If that's not correct to keep old values for already stored data, then more complex change is needed.

b) I left there some valgind varnings, namely these two:
------------------------------------------------------------------------------
b1) mails with attachments
==15651== Invalid read of size 4
==15651==    at 0x6111704: get_SPropValue (property.c:91)
==15651==    by 0x56E41F9: exchange_mapi_util_find_SPropVal_array_propval (exchange-mapi-utils.c:127)
==15651==    by 0x646FD3A: mapi_folder_item_to_msg (camel-mapi-folder.c:1278)
==15651==    by 0x64701AF: mapi_folder_get_message (camel-mapi-folder.c:1392)
==15651==    by 0x42BBB03: camel_folder_get_message (camel-folder.c:1150)
==15651==    by 0x60953B8: get_message_exec (mail-ops.c:1830)
==15651==    by 0x6097F89: mail_msg_proxy (mail-mt.c:520)
==15651==    by 0x4D1CDDB: g_thread_pool_thread_proxy (gthreadpool.c:265)
==15651==    by 0x4D1B66C: g_thread_create_proxy (gthread.c:635)
==15651==    by 0x43451E: start_thread (pthread_create.c:297)
==15651==    by 0x39501D: clone (clone.S:130)
==15651==  Address 0x4ec4868 is 0 bytes after a block of size 256 alloc'd
==15651==    at 0x4004BA2: calloc (vg_replace_malloc.c:397)
==15651==    by 0x4CF5409: g_malloc0 (gmem.c:151)
==15651==    by 0x56DDE80: exchange_mapi_util_get_attachments (exchange-mapi-connection.c:677)
==15651==    by 0x56DFA82: exchange_mapi_connection_fetch_item (exchange-mapi-connection.c:1329)
==15651==    by 0x6470153: mapi_folder_get_message (camel-mapi-folder.c:1380)
==15651==    by 0x42BBB03: camel_folder_get_message (camel-folder.c:1150)
==15651==    by 0x60953B8: get_message_exec (mail-ops.c:1830)
==15651==    by 0x6097F89: mail_msg_proxy (mail-mt.c:520)
==15651==    by 0x4D1CDDB: g_thread_pool_thread_proxy (gthreadpool.c:265)
==15651==    by 0x4D1B66C: g_thread_create_proxy (gthread.c:635)
==15651==    by 0x43451E: start_thread (pthread_create.c:297)
==15651==    by 0x39501D: clone (clone.S:130)

------------------------------------------------------------------------------
b2) leak on folder info fetch
==15651== 1,535 bytes in 55 blocks are definitely lost in loss record 204 of 300
==15651==    at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==15651==    by 0x318CF7: vasprintf (vasprintf.c:77)
==15651==    by 0x4D2B12F: g_vasprintf (gprintf.c:315)
==15651==    by 0x4D1045B: g_strdup_vprintf (gstrfuncs.c:244)
==15651==    by 0x4D1047E: g_strdup_printf (gstrfuncs.c:270)
==15651==    by 0x64738E2: mapi_folders_sync (camel-mapi-store.c:1263)
==15651==    by 0x6473BCE: mapi_get_folder_info (camel-mapi-store.c:1336)
==15651==    by 0x42DAA18: camel_store_get_folder_info (camel-store.c:897)
==15651==    by 0x6094198: get_folderinfo_exec (mail-ops.c:1075)
==15651==    by 0x6097F89: mail_msg_proxy (mail-mt.c:520)
==15651==    by 0x4D1CDDB: g_thread_pool_thread_proxy (gthreadpool.c:265)
==15651==    by 0x4D1B66C: g_thread_create_proxy (gthread.c:635)

------------------------------------------------------------------------------
There are also some warnings about leaking in windows_to_utf8 function, but I guess it's rather question of my older openchange package than real issue.