GNOME Bugzilla – Bug 628426
imapx refresh_info memory leak
Last modified: 2013-09-14 16:54:14 UTC
==31850== 146,624 (8,480 direct, 138,144 indirect) bytes in 212 blocks are definitely lost in loss record 42,562 of 42,639 ==31850== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==31850== by 0x3D3D645C80: g_malloc (gmem.c:134) ==31850== by 0x3D3D65C796: g_slice_alloc (gslice.c:836) ==31850== by 0x669F8AF: camel_folder_change_info_new (camel-folder.c:2527) ==31850== by 0x1A25A94A: imapx_server_fetch_new_messages (camel-imapx-server.c:2174) ==31850== by 0x1A261968: imapx_job_refresh_info_start (camel-imapx-server.c:3979) ==31850== by 0x1A25A2FB: imapx_run_job (camel-imapx-server.c:2039) ==31850== by 0x1A25B33D: camel_imapx_server_refresh_info (camel-imapx-server.c:5153) ==31850== by 0x1A259E1B: imapx_refresh_info (camel-imapx-folder.c:169) ==31850== by 0x66A2EB9: camel_folder_refresh_info (camel-folder.c:1156) ==31850== by 0xF17B005: refresh_folders_exec (mail-send-recv.c:912)
Created attachment 169601 [details] [review] eds patch for evolution-data-server; It seems it can be freed always, not only when called in an asynchronous mode.
Created commit aac3dff in eds master (2.31.92+)
See bug 628490, and... ==13856== Invalid free() / delete / delete[] ==13856== at 0x4A04D72: free (vg_replace_malloc.c:325) ==13856== by 0x3D3D645DC2: g_free (gmem.c:204) ==13856== by 0x3D3D65CB50: g_slice_free1 (gslice.c:901) ==13856== by 0x3D3D617537: g_ptr_array_free (garray.c:953) ==13856== by 0x669EF9A: camel_folder_change_info_free (camel-folder.c:2943) ==13856== by 0x1A2645A3: camel_imapx_server_refresh_info (camel-imapx-server.c:5169) ==13856== by 0x1A26302B: imapx_refresh_info (camel-imapx-folder.c:174) ==13856== by 0x66A2F29: camel_folder_refresh_info (camel-folder.c:1156) ==13856== by 0xF17E1C5: refresh_folders_exec (mail-send-recv.c:912) ==13856== by 0xF1775C7: mail_msg_proxy (mail-mt.c:469) ==13856== by 0x3D3D668EC3: g_thread_pool_thread_proxy (gthreadpool.c:314) ==13856== by 0x3D3D666745: g_thread_create_proxy (gthread.c:1897) ==13856== Address 0x24d462c0 is 0 bytes inside a block of size 32 free'd ==13856== at 0x4A04D72: free (vg_replace_malloc.c:325) ==13856== by 0x3D3D645DC2: g_free (gmem.c:204) ==13856== by 0x3D3D65CB50: g_slice_free1 (gslice.c:901) ==13856== by 0x3D3D617537: g_ptr_array_free (garray.c:953) ==13856== by 0x669EF9A: camel_folder_change_info_free (camel-folder.c:2943) ==13856== by 0x1A269928: imapx_command_step_fetch_done (camel-imapx-server.c:3561) ==13856== by 0x1A26C187: imapx_step (camel-imapx-server.c:1906) ==13856== by 0x1A26D41A: parse_contents (camel-imapx-server.c:4580) ==13856== by 0x1A26D84A: imapx_parser_thread (camel-imapx-server.c:4647) ==13856== by 0x3D3D666745: g_thread_create_proxy (gthread.c:1897) ==13856== by 0x359B007760: start_thread (pthread_create.c:301) ==13856== by 0x359A8E14EC: clone (clone.S:115)
Sorry, bug 628940.
*** Bug 628940 has been marked as a duplicate of this bug. ***
The imapx_command_step_fetch_done was used on two places, one was with the refresh_info command, and the other with fetch_new_messages command, the refresh routine frees the 'changes' pointer itself, same as the step_fetch_done, but the step_fetch_done is called from refresh_info by imapx_job_scan_changes_done, through imapx_job_scan_changes_start, which is using the same 'job' as imapx_job_refresh_info_start, from where it is called. Thus the fix is to free the 'changes' pointer in step_fetch_done only when it is called for a FETCH_NEW_MESSAGES job, otherwise keep it as it is (and the refresh_info caller will take care of it). I'm only wondering whether the above makes any sense to anyone, as I'm not much sure whether I understand it myself enough :)
Created attachment 169753 [details] [review] eds patch (for a caused crash) for evolution-data-server; To have it complete, here's a patch for the crash I caused.
Created commit b017085 in eds master (2.31.92+)