GNOME Bugzilla – Bug 702022
Memory leak with recurring event
Last modified: 2013-08-09 14:33:37 UTC
==21714== 14 bytes in 1 blocks are definitely lost in loss record 408 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 0x3768064C4E: g_strdup (gstrfuncs.c:364) ==21714== by 0x3DE1226781: get_datetime (e-cal-component.c:2506) ==21714== by 0x3DE123257A: e_cal_recur_generate_instances_of_rule (e-cal-recur.c:691) ==21714== by 0x3DE1233B6E: e_cal_recur_generate_instances (e-cal-recur.c:640) ==21714== by 0x3DE0615308: func_occur_in_time_range (e-cal-backend-sexp.c:200) ==21714== by 0x3DDFE379CF: e_sexp_term_eval (e-sexp.c:784) ==21714== by 0x3DDFE38822: e_sexp_eval (e-sexp.c:1698) ==21714== by 0x3DE0616A96: e_cal_backend_sexp_match_comp (e-cal-backend-sexp.c:1254) ==21714== by 0xF950185: caldav_get_object_list (e-cal-backend-caldav.c:4744) ==21714== by 0x3DE0617E93: cal_backend_get_object_list (e-cal-backend-sync.c:634) ==21714== ==21714== 14 bytes in 1 blocks are definitely lost in loss record 409 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 0x3768064C4E: g_strdup (gstrfuncs.c:364) ==21714== by 0x3DE1226781: get_datetime (e-cal-component.c:2506) ==21714== by 0x3DE1229084: e_cal_component_get_dtend (e-cal-component.c:2643) ==21714== by 0x3DE1232595: e_cal_recur_generate_instances_of_rule (e-cal-recur.c:692) ==21714== by 0x3DE1233B6E: e_cal_recur_generate_instances (e-cal-recur.c:640) ==21714== by 0x3DE0615308: func_occur_in_time_range (e-cal-backend-sexp.c:200) ==21714== by 0x3DDFE379CF: e_sexp_term_eval (e-sexp.c:784) ==21714== by 0x3DDFE38822: e_sexp_eval (e-sexp.c:1698) ==21714== by 0x3DE0616A96: e_cal_backend_sexp_match_comp (e-cal-backend-sexp.c:1254) ==21714== by 0xF950185: caldav_get_object_list (e-cal-backend-caldav.c:4744) ==21714==
And here's a similar one for EWS. Don't even know if this one is recurring, in fact. ==21714== 22 bytes in 1 blocks are definitely lost in loss record 1,882 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 0x3768064C4E: g_strdup (gstrfuncs.c:364) ==21714== by 0x3DE1226781: get_datetime (e-cal-component.c:2506) ==21714== by 0x3DE1238E7D: e_cal_util_get_component_occur_times (e-cal-util.c:1277) ==21714== by 0x3DE061C6A1: cal_backend_store_load (e-cal-backend-store.c:277) ==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== by 0x376806C224: g_thread_proxy (gthread.c:798) ==21714== by 0x3909607C52: start_thread (pthread_create.c:308) ==21714==
Lots of these... ==21714== 48 bytes in 1 blocks are definitely lost in loss record 3,305 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 0x3DE1226726: get_datetime (e-cal-component.c:2498) ==21714== by 0x3DE1238E7D: e_cal_util_get_component_occur_times (e-cal-util.c:1277) ==21714== by 0x3DE061C6A1: cal_backend_store_load (e-cal-backend-store.c:277) ==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== by 0x376806C224: g_thread_proxy (gthread.c:798) ==21714== by 0x3909607C52: start_thread (pthread_create.c:308) ==21714== by 0x39092F4ECC: clone (clone.S:113) ==21714== ==21714== 48 bytes in 1 blocks are definitely lost in loss record 3,306 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 0x3DE1226726: get_datetime (e-cal-component.c:2498) ==21714== by 0x3DE123257A: e_cal_recur_generate_instances_of_rule (e-cal-recur.c:691) ==21714== by 0x3DE1233B6E: e_cal_recur_generate_instances (e-cal-recur.c:640) ==21714== by 0x3DE0615308: func_occur_in_time_range (e-cal-backend-sexp.c:200) ==21714== by 0x3DDFE379CF: e_sexp_term_eval (e-sexp.c:784) ==21714== by 0x3DDFE38822: e_sexp_eval (e-sexp.c:1698) ==21714== by 0x3DE0616A96: e_cal_backend_sexp_match_comp (e-cal-backend-sexp.c:1254) ==21714== by 0xF950185: caldav_get_object_list (e-cal-backend-caldav.c:4744) ==21714== by 0x3DE0617E93: cal_backend_get_object_list (e-cal-backend-sync.c:634) ==21714== by 0x3DE061FEA6: operation_thread (e-data-cal.c:529) ==21714== ==21714== 48 bytes in 1 blocks are definitely lost in loss record 3,307 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 0x3DE1226726: get_datetime (e-cal-component.c:2498) ==21714== by 0x3DE1229084: e_cal_component_get_dtend (e-cal-component.c:2643) ==21714== by 0x3DE1232595: e_cal_recur_generate_instances_of_rule (e-cal-recur.c:692) ==21714== by 0x3DE1233B6E: e_cal_recur_generate_instances (e-cal-recur.c:640) ==21714== by 0x3DE0615308: func_occur_in_time_range (e-cal-backend-sexp.c:200) ==21714== by 0x3DDFE379CF: e_sexp_term_eval (e-sexp.c:784) ==21714== by 0x3DDFE38822: e_sexp_eval (e-sexp.c:1698) ==21714== by 0x3DE0616A96: e_cal_backend_sexp_match_comp (e-cal-backend-sexp.c:1254) ==21714== by 0xF950185: caldav_get_object_list (e-cal-backend-caldav.c:4744) ==21714== by 0x3DE0617E93: cal_backend_get_object_list (e-cal-backend-sync.c:634) ==21714==
I see all e_cal_component_get_dtstart()/e_cal_component_get_dtend() has their corresponding e_cal_component_free_datetime() call, thus this feels like a false-positive, unless you killed it in the middle of the work.