GNOME Bugzilla – Bug 531197
memleaks
Last modified: 2008-05-14 17:00:03 UTC
From the SyncEvolution nightly testing, using Evolution 2.22.x. In libecal: ==24572== 408 bytes in 8 blocks are definitely lost in loss record 16 of 37 ==24572== at 0x401D4B0: malloc (vg_replace_malloc.c:149) ==24572== by 0x44F417F: strdup (in /lib/tls/i686/cmov/libc-2.3.6.so) ==24572== by 0x4083A4C: icalmemory_strdup (icalmemory.c:240) ==24572== by 0x4072E3F: icalparameter_new_from_value_string (icalderivedparameter.c:1475) ==24572== by 0x4086438: icalparser_add_line (icalparser.c:861) ==24572== by 0x4085CB3: icalparser_parse (icalparser.c:591) ==24572== by 0x4086B02: icalparser_parse_string (icalparser.c:1132) ==24572== by 0x407EA6E: icalcomponent_new_from_string (icalcomponent.c:173) [...] The "string" pointer is overwritten without freeing the old string. In EDS: ==24559== 476 bytes in 28 blocks are definitely lost in loss record 28 of 57 ==24559== at 0x401D4B0: malloc (vg_replace_malloc.c:149) ==24559== by 0x4814A99: icalmemory_new_buffer (icalmemory.c:262) ==24559== by 0x481E3A0: icaltime_as_ical_string (icaltime.c:454) ==24559== by 0x47EF1A4: e_cal_component_get_recurid_as_string (e-cal-component.c:3580) ==24559== by 0x5350517: add_component (e-cal-backend-file.c:478) ==24559== by 0x535319B: e_cal_backend_file_create_object (e-cal-backend-file.c:1850) ==24559== by 0x412C941: e_cal_backend_sync_create_object (e-cal-backend-sync.c:232) ==24559== by 0x412E596: _e_cal_backend_create_object (e-cal-backend-sync.c:727) ==24559== by 0x4125F60: e_cal_backend_create_object (e-cal-backend.c:894) ==24559== by 0x412FB16: impl_Cal_createObject (e-data-cal.c:324) ==24559== by 0x411DE00: _ORBIT_skel_small_GNOME_Evolution_Calendar_Cal_createObject (Evolution-DataServer-Calendar-common.c:112) ==24559== by 0x43AC436: ORBit_POAObject_invoke (poa.c:1142) ==24559== by 0x43B2664: ORBit_OAObject_invoke (orbit-adaptor.c:338) ==24559== by 0x439F5D8: ORBit_small_invoke_adaptor (orbit-small.c:844) ==24559== by 0x43B02B9: ORBit_POAObject_handle_request (poa.c:1351) ==24559== by 0x43B095B: ORBit_POAObject_invoke_incoming_request (poa.c:1421) ==24559== by 0x439813A: giop_thread_queue_process (giop.c:771) ==24559== by 0x43989D7: giop_request_handler_thread (giop.c:481) ==24559== by 0x4478306: g_thread_pool_thread_proxy (gthreadpool.c:265) ==24559== by 0x447677E: g_thread_create_proxy (gthread.c:635) ==24559== by 0x452623F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==24559== by 0x45FE49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) This code has not been updated to the new e_cal_component_get_recurid_as_string() semantic (bug #516408). Will attach a patch which fixed these leaks for me. Please commit.
Created attachment 110309 [details] [review] fixes memleaks in libical and Calendar file backend
Created attachment 110354 [details] [review] fixes memory leaks in calendar file backend caused by semantic change of ecal function
Created attachment 110355 [details] [review] setting string properties leaked any existing string
I wonder if your using a old code. I see the patch at comment #2 is taken care of already. I am looking at code from trunk. The patch at comment #3 looks good to commit.
Regarding comment #2, I was looking at the 2.22 branch. Has the problem perhaps only been fixed on the trunk? If so, why?
Ah so it should be committed to stable too. No reason why it should not be committed ;-) Just commented at bug 523541.
Applied patch at comment #3 to gnome-2-22 and trunk. I'm keeping this issue open until the other memory leak is also fixed on gnome-2-22.
The commit r8791 on 2008-05-14 by Milan Crha fixed this issue also on the 2.22.x branch.