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 627614 - add_instance() memory leak
add_instance() memory leak
Status: RESOLVED INCOMPLETE
Product: evolution
Classification: Applications
Component: Calendar
2.32.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks: 627707
 
 
Reported: 2010-08-21 23:58 UTC by David Woodhouse
Modified: 2012-06-26 10:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Woodhouse 2010-08-21 23:58:19 UTC 
==30229== 6,316 bytes in 310 blocks are definitely lost in loss record 25,329 of 25,853
==30229==    at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==30229==    by 0x359A87FD51: strdup (strdup.c:43)
==30229==    by 0x3EFB42EDF4: icalparameter_new_clone (icalparameter.c:132)
==30229==    by 0x3EFB43151B: icalproperty_new_clone (icalproperty.c:157)
==30229==    by 0x3EFB42D44F: icalcomponent_new_clone (icalcomponent.c:199)
==30229==    by 0x6D854B2: add_instance (e-cal.c:2536)
==30229==    by 0x6D8A16B: generate_instances (e-cal.c:2857)
==30229==    by 0x6D8B9C6: e_cal_generate_instances_for_object (e-cal.c:2991)
==30229==    by 0xEC1EFA9: process_added (e-cal-model.c:1771)
==30229==    by 0xEC1C5F7: process_event (e-cal-model.c:1959)
==30229==    by 0xEC1C7D5: e_cal_view_objects_added_cb (e-cal-model.c:1987)
==30229==    by 0x3A4E40D7BD: g_closure_invoke (in /lib64/libgobject-2.0.so.0.2512.0)
Comment 1 Milan Crha 2010-09-06 14:37:34 UTC 
I cannot reproduce this myself, my recurring events aren't triggering this. Could you try to provide some test data or a recurring rule which invokes this, please? Thanks in advance.
Comment 2 David Woodhouse 2010-09-06 19:24:53 UTC 
it was when I created a new event (in a Google caldav calendar). Will try to reproduce...
Comment 3 Felipe Besoaín Pino 2010-10-20 12:03:08 UTC 
any news about this?, david this still an issue? can try a newest version please?
Comment 4 David Woodhouse 2010-10-20 12:38:30 UTC 
Looking through the valgrind output for my currently-running evolution, I see it's still happening:

==24122== 1,616 bytes in 80 blocks are definitely lost in loss record 35,230 of 36,740
==24122==    at 0x4A0615D: malloc (vg_replace_malloc.c:195)
==24122==    by 0x3B2C082941: strdup (strdup.c:43)
==24122==    by 0x3B4102F0A4: icalparameter_new_clone (icalparameter.c:139)
==24122==    by 0x3B41030E7B: icalproperty_new_clone (icalproperty.c:157)
==24122==    by 0x3B4102A4FF: icalcomponent_new_clone (icalcomponent.c:208)
==24122==    by 0x6B5D472: add_instance (e-cal.c:2648)
==24122==    by 0x6B6391B: generate_instances (e-cal.c:2969)
==24122==    by 0x6B66596: e_cal_generate_instances_for_object (e-cal.c:3103)
==24122==    by 0xFE4F1EF: process_added (e-cal-model.c:1781)
==24122==    by 0xFE493AB: process_event (e-cal-model.c:1969)
==24122==    by 0xFE49595: e_cal_view_objects_added_cb (e-cal-model.c:1997)
==24122==    by 0x3B2EC0E03D: g_closure_invoke (gclosure.c:766)
Comment 5 Milan Crha 2012-06-26 10:18:29 UTC 
I suppose this is obsolete. I checked the code of ECalClient, where this was copied to, and I see the ECalComponent (the newly created icalcomponent is passed into it as expected) being properly unreffed in the generate_instances. Please reopen if you see anything like this in 3.4.x+. Thanks in advance.