GNOME Bugzilla – Bug 702029
caldav synchronize_cache() leak
Last modified: 2015-04-21 14:22:38 UTC
==21714== 976 (16 direct, 960 indirect) bytes in 1 blocks are definitely lost in loss record 6,563 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x376804D93E: g_malloc (gmem.c:159) ==21714== by 0x37680634ED: g_slice_alloc (gslice.c:1003) ==21714== by 0x37680642E5: g_slist_prepend (gslist.c:267) ==21714== by 0x3DE061C11A: e_cal_backend_store_get_components_occuring_in_range (e-cal-backend-store.c:1375) ==21714== by 0xF9501E9: caldav_get_object_list (e-cal-backend-caldav.c:4738) ==21714== by 0x3DE0617E93: cal_backend_get_object_list (e-cal-backend-sync.c:634) ==21714== by 0x3DE061FEA6: operation_thread (e-data-cal.c:529) ==21714== by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309) ==21714== by 0x376806C224: g_thread_proxy (gthread.c:798) ==21714== by 0x3909607C52: start_thread (pthread_create.c:308) ==21714== by 0x39092F4ECC: clone (clone.S:113)
==21714== 2,032 bytes in 1 blocks are definitely lost in loss record 6,682 of 7,013 ==21714== at 0x4A08121: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x376804D996: g_malloc0 (gmem.c:189) ==21714== by 0x376801A918: thread_memory_from_self.part.12 (gslice.c:512) ==21714== by 0x3768063634: g_slice_alloc (gslice.c:1561) ==21714== by 0x3768063A2D: g_slice_alloc0 (gslice.c:1029) ==21714== by 0x3D03871DBE: soup_uri_new_with_base (soup-uri.c:256) ==21714== by 0x3D03872902: soup_uri_new (soup-uri.c:480) ==21714== by 0x3D03859CAA: soup_message_new (soup-message.c:882) ==21714== by 0xF950B6F: synchronize_cache (e-cal-backend-caldav.c:1261) ==21714== by 0xF9523CD: caldav_synch_slave_loop (e-cal-backend-caldav.c:2513) ==21714== by 0x376806C224: g_thread_proxy (gthread.c:798) ==21714== by 0x3909607C52: start_thread (pthread_create.c:308) ==21714== ==21714== 3,872 bytes in 4 blocks are definitely lost in loss record 6,759 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x3915AAACE1: xmlGetGlobalState (threads.c:583) ==21714== by 0x3915AAA2D4: __xmlDefaultSAXHandler (globals.c:832) ==21714== by 0x3915B03058: xmlDefaultSAXHandlerInit (SAX2.c:2913) ==21714== by 0x3915A383B1: xmlInitParserCtxt (parserInternals.c:1573) ==21714== by 0x3915A38B5B: xmlNewParserCtxt (parserInternals.c:1834) ==21714== by 0x3915A4BFC7: xmlCreateMemoryParserCtxt (parser.c:14364) ==21714== by 0x3915A519BA: xmlSAXParseMemoryWithData (parser.c:14418) ==21714== by 0x3DDFE56DE3: e_xml_parse_file (e-xml-utils.c:60) ==21714== by 0x3DDFE57763: e_xmlhash_new (e-xml-hash-utils.c:205) ==21714== by 0x3DE0231456: file_cache_constructed (e-file-cache.c:135) ==21714== by 0x3CFCC15F94: g_object_newv (gobject.c:1747) ==21714==
oops, posted the wrong trace when filing this bug. I think this is the one I thought I'd included: ==21714== 968 bytes in 1 blocks are definitely lost in loss record 6,561 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x3915AAACE1: xmlGetGlobalState (threads.c:583) ==21714== by 0x3915AAA264: __xmlDefaultBufferSize (globals.c:814) ==21714== by 0x3915AAE989: xmlBufCreate (buf.c:133) ==21714== by 0x3915A63A12: xmlAllocOutputBuffer (xmlIO.c:2457) ==21714== by 0xF950C0E: synchronize_cache (e-cal-backend-caldav.c:1275) ==21714== by 0xF9523CD: caldav_synch_slave_loop (e-cal-backend-caldav.c:2513) ==21714== by 0x376806C224: g_thread_proxy (gthread.c:798) ==21714== by 0x3909607C52: start_thread (pthread_create.c:308) ==21714== by 0x39092F4ECC: clone (clone.S:113)
The one in comment 2 looks like a valgrind false positive too. The buffer is allocated at line 1275 in synchronize_cache(), and unconditionally freed again at line 1297 when we're done with it.
the comment #0 is part of bug #702031. It seems to me that valgrind is cheating you.
I do not see anyone of the above leaks in current git master, which is pretty much the same as 3.16.1, thus I'm closing this.