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 702021 - ical error memory leak
ical error memory leak
Status: RESOLVED NOTABUG
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 15:43 UTC by David Woodhouse
Modified: 2013-06-12 08:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Woodhouse 2013-06-11 15:43:15 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)
Comment 1 David Woodhouse 2013-06-11 15:43:58 UTC
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==
Comment 2 David Woodhouse 2013-06-11 15:44:42 UTC
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)
Comment 3 David Woodhouse 2013-06-12 08:24:00 UTC
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.