GNOME Bugzilla – Bug 712135
Memory leak around sync_hierarchy_response_cb()
Last modified: 2013-11-13 11:16:24 UTC
2,458 bytes in 2 blocks are definitely lost in loss record 29,424 of 31,220 at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x390244D89E: g_malloc (gmem.c:159) by 0x3902464BAE: g_strdup (gstrfuncs.c:364) by 0x13615AFA: e_soap_parameter_get_string_value (e-soap-response.c:349) by 0x135F7550: sync_xxx_response_cb (e-ews-connection.c:648) by 0x136031E4: sync_hierarchy_response_cb (e-ews-connection.c:755) by 0x135FD16A: ews_response_cb (e-ews-connection.c:623) by 0x39FD86C263: ??? (in /usr/lib64/libsoup-2.4.so.1.6.0) by 0x39FD86C464: ??? (in /usr/lib64/libsoup-2.4.so.1.6.0) by 0x39FD86C4EA: ??? (in /usr/lib64/libsoup-2.4.so.1.6.0) by 0x3902447E05: g_main_context_dispatch (gmain.c:3054) by 0x3902448157: g_main_context_iterate.isra.22 (gmain.c:3701) by 0x3902448559: g_main_loop_run (gmain.c:3895) by 0x135F679D: e_ews_soup_thread (e-ews-connection.c:1538) by 0x390246C184: g_thread_proxy (gthread.c:798) by 0x3900007C52: start_thread (in /usr/lib64/libpthread-2.17.so) by 0x38FFCF513C: clone (in /usr/lib64/libc-2.17.so) No extra reproducer, just run evolution like this: $ valgrind --num-callers=50 --leak-check=full evolution &>log.txt and let it collect the log. The 'definitely' lost memory is a clear leak, while 'possibly lost' memory is a theoretical leak, when the object has a reference somewhere, probably in a global memory/cache. Consider also exporting: G_SLICE=always-malloc to get even better memory checker (GSLice is a global memory pool, thus it can move some 'definitely' leaks into 'possibly lost' group.
I do believe this leak was caused by the last but one version of the "List for server change notifications" (https://bugzilla.gnome.org/show_bug.cgi?id=699349) patch. Milan, I've committed the patch with the fix squashed on it. Running evolution with the suggested command line I'm not able to see those lost blocks. I would like to ask you to run it again (with git master) and let me know if you still can see the same problem. If not, we can close this as "INVALID" or "OBSOLETE".
Nice, I'm not able to reproduce it too, with ews master at commit 5bf3c20. *** This bug has been marked as a duplicate of bug 699349 ***