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 702032 - e_cal_backend_store leak.
e_cal_backend_store 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:13 UTC by David Woodhouse
Modified: 2015-04-21 16:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Woodhouse 2013-06-11 16:13:45 UTC 
==21714== 10,969 (376 direct, 10,593 indirect) bytes in 1 blocks are definitely lost in loss record 6,892 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 0x3768063A2D: g_slice_alloc0 (gslice.c:1029)
==21714==    by 0x3CFCC2FA05: g_type_create_instance (gtype.c:1897)
==21714==    by 0x3CFCC14597: g_object_constructor (gobject.c:1855)
==21714==    by 0x3CFCC16010: g_object_newv (gobject.c:1638)
==21714==    by 0x3CFCC1666B: g_object_new (gobject.c:1548)
==21714==    by 0x3DE1227489: e_cal_component_new (e-cal-component.c:434)
==21714==    by 0x3DE061C65C: cal_backend_store_load (e-cal-backend-store.c:269)
==21714==    by 0x3DE061B782: e_cal_backend_store_load (e-cal-backend-store.c:1111)
==21714==    by 0xCF7D777: e_cal_backend_ews_o
Comment 1 Milan Crha 2013-08-09 14:01:47 UTC 
Hmm, I do not see how this could happen in the above backtrace. The only thing is that some function asked for a component, but didn't unref it when it should. Strange is that it's only one block, not many (which I understand as only once component, while you might have more than one component in your calendar).
Comment 2 Milan Crha 2015-04-21 16:51:36 UTC 
I did not see this one with git master, pretty much the same as 3.16.1. I see a similar report:
==16674== 4 bytes in 1 blocks are definitely lost in loss record 53 of 8,170
==16674==    at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck...
==16674==    by 0x5B8BBC7: icalerrno_return (icalerror.c:64)
==16674==    by 0x5B8BCF5: icalerror_clear_errno (icalerror.c:114)
==16674==    by 0x5B76B37: icalparameter_get_value (icalderivedparameter.c:1620)
==16674==    by 0x5B8F50A: icalparser_add_line (icalparser.c:1045)
==16674==    by 0x5B8E9D2: icalparser_parse (icalparser.c:631)
==16674==    by 0x55CAA5A: e_cal_util_parse_ics_file (e-cal-util.c:241)
==16674==    by 0x536A19F: cal_backend_store_load (e-cal-backend-store.c:641)
==16674==    by 0x536B14A: e_cal_backend_store_load (e-cal-backend-store.c:1131)
==16674==    by 0x1BB14FF8: e_cal_backend_ews_open (e-cal-backend-ews.c:797)
==16674==    by 0x535A837: cal_backend_open_thread (e-cal-backend.c:1558)
==16674==    by 0x5357C9A: cal_backend_dispatch_thread (e-cal-backend.c:241)


but that looks correct in the libical sources. The memory in question is a thread-specific pthread-allocated memory, which is supposed to be freed on the thread end. I guess this is a false-positive then.