After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 702030 - caldav_do_open() / e_source_get_extension() leak.
caldav_do_open() / e_source_get_extension() leak.
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.8.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks: 627707
 
 
Reported: 2013-06-11 16:09 UTC by David Woodhouse
Modified: 2015-04-21 16:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Woodhouse 2013-06-11 16:09:02 UTC 
==21714== 2,032 bytes in 1 blocks are definitely lost in loss record 6,680 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 0x3768037A0D: g_hash_table_new_full (ghash.c:653)
==21714==    by 0x3DDFE3BAAB: e_source_get_extension (e-source.c:227)
==21714==    by 0xF94A7AF: initialize_backend (e-cal-backend-caldav.c:2719)
==21714==    by 0xF95213C: caldav_do_open (e-cal-backend-caldav.c:2880)
==21714==    by 0x3DE0617278: cal_backend_open (e-cal-backend-sync.c:559)
==21714==    by 0x3DE061FE15: operation_thread (e-data-cal.c:504)
==21714==    by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309)
==21714==    by 0x376806C224: g_thread_proxy (gthread.c:798)
Comment 1 David Woodhouse 2013-06-11 16:12:57 UTC 
Here's a similar one for EWS:

==21714== 8,128 bytes in 4 blocks are definitely lost in loss record 6,865 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 0x3768037A0D: g_hash_table_new_full (ghash.c:653)
==21714==    by 0x3DDFE3BAAB: e_source_get_extension (e-source.c:227)
==21714==    by 0xCF7D730: e_cal_backend_ews_open (e-cal-backend-ews.c:629)
==21714==    by 0x3DE061FE15: operation_thread (e-data-cal.c:504)
==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==
Comment 2 Matthew Barnes 2013-06-11 16:38:37 UTC 
These look bogus as well.

The hash table being allocated in source_find_extension_classes() is freed by the caller on line 2282 with no way around it.
Comment 3 Matthew Barnes 2013-06-11 16:40:06 UTC 
I'm seeing g_slice_alloc() in a lot of these backtraces.  GLib's slice allocator is known to confuse valgrind.  Better to run with G_SLICE=always-malloc.
Comment 4 David Woodhouse 2013-06-11 16:51:00 UTC 
I am. You'll note that g_malloc0() ends up calling directly into (valgrind's overridden version of) calloc().

I did fix attempt to fix that one, but it triggered valgrind bugs:
http://valgrind.10908.n7.nabble.com/Mempool-annotation-for-glib-gslice-td42665.html

See also bug 627423 (Make glib valgrind-friendly)
Comment 5 Milan Crha 2015-04-21 16:08:07 UTC 
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.