GNOME Bugzilla – Bug 702021
ical error memory leak
Last modified: 2013-06-12 08:24:00 UTC
==21714== 4 bytes in 1 blocks are definitely lost in loss record 52 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x392442D8E9: icalerrno_return (icalerror.c:64) ==21714== by 0x392442D938: icalerror_clear_errno (icalerror.c:114) ==21714== by 0x392441BA18: icalparameter_get_value (icalderivedparameter.c:1360) ==21714== by 0x392442FB49: icalparser_add_line (icalparser.c:995) ==21714== by 0x392443009C: icalparser_parse (icalparser.c:621) ==21714== by 0x3DE12370C9: e_cal_util_parse_ics_file (e-cal-util.c:242) ==21714== by 0x3DE061C5EB: cal_backend_store_load (e-cal-backend-store.c:634) ==21714== by 0x3DE061B782: e_cal_backend_store_load (e-cal-backend-store.c:1111) ==21714== by 0xF94AB22: initialize_backend (e-cal-backend-caldav.c:2796) ==21714== by 0xF95213C: caldav_do_open (e-cal-backend-caldav.c:2880) ==21714== by 0x3DE0617278: cal_backend_open (e-cal-backend-sync.c:559)
Hm, perhaps not caldav-specific. Here's a very similar one with EWS: ==21714== 8 bytes in 2 blocks are definitely lost in loss record 299 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x392442D8E9: icalerrno_return (icalerror.c:64) ==21714== by 0x392442D938: icalerror_clear_errno (icalerror.c:114) ==21714== by 0x392441BA18: icalparameter_get_value (icalderivedparameter.c:1360) ==21714== by 0x392442FB49: icalparser_add_line (icalparser.c:995) ==21714== by 0x392443009C: icalparser_parse (icalparser.c:621) ==21714== by 0x3DE12370C9: e_cal_util_parse_ics_file (e-cal-util.c:242) ==21714== by 0x3DE061C5EB: cal_backend_store_load (e-cal-backend-store.c:634) ==21714== by 0x3DE061B782: e_cal_backend_store_load (e-cal-backend-store.c:1111) ==21714== by 0xCF7D777: e_cal_backend_ews_open (e-cal-backend-ews.c:637) ==21714== by 0x3DE061FE15: operation_thread (e-data-cal.c:504) ==21714== by 0x376806CBE5: g_thread_pool_thread_proxy (gthreadpool.c:309) ==21714==
And this is slightly different, but quite possibly related: ==21714== 8 bytes in 2 blocks are definitely lost in loss record 300 of 7,013 ==21714== at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21714== by 0x392442D8E9: icalerrno_return (icalerror.c:64) ==21714== by 0x392442DBA7: icalerror_set_errno (icalerror.c:100) ==21714== by 0x392442A040: icalcomponent_new_clone (icalcomponent.c:192) ==21714== by 0x3DE060F9B9: cal_backend_add_cached_timezone (e-cal-backend.c:422) ==21714== by 0x3DE061B42C: cal_backend_store_set_default_timezone (e-cal-backend-store.c:790) ==21714== by 0xCF7D880: e_cal_backend_ews_open (e-cal-backend-ews.c:641) ==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)
This is probably valgrind failing to track thread-local storage. The code in icalerrno_return() looks like this: _errno = (icalerrorenum*) pthread_getspecific(icalerrno_key); if (!_errno) { _errno = malloc(sizeof(icalerrorenum)); *_errno = ICAL_NO_ERROR; pthread_setspecific(icalerrno_key, _errno); } return _errno; It *does* also have a destructor, set up with pthread_key_create(), which looks like it'll properly free the memory on thread exit. I think this is a valgrind bug. Bug 702023 is probably similar.