GNOME Bugzilla – Bug 627617
calendar memory leak
Last modified: 2013-09-13 01:05:55 UTC
Probably due to me leaving a read-only event editor dialog open while the webcal refreshed? ==23683== 174 bytes in 3 blocks are definitely lost in loss record 21,310 of 26,937 ==23683== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==23683== by 0x3A4DC45784: g_malloc (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC5D2DD: g_strdup (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75721: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75481: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75C48: g_variant_get_va (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75E85: g_variant_get (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x6DA5E56: e_gdbus_cal_call_get_query_sync (e-gdbus-egdbuscal.c:4062) ==23683== by 0x6D86415: e_cal_get_query (e-cal.c:3844) ==23683== by 0xEC1C210: update_e_cal_view_for_client (e-cal-model.c:2066) ==23683== by 0xEC1F0B2: add_new_client (e-cal-model.c:2171) ==23683== by 0x1049C293: task_shell_view_selector_client_added_cb (e-task-shell-view-private.c:90) ==23683== ==23683== 174 bytes in 3 blocks are definitely lost in loss record 21,311 of 26,937 ==23683== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==23683== by 0x3A4DC45784: g_malloc (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC5D2DD: g_strdup (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75721: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75481: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75C48: g_variant_get_va (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75E85: g_variant_get (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x6DA5E56: e_gdbus_cal_call_get_query_sync (e-gdbus-egdbuscal.c:4062) ==23683== by 0x6D86415: e_cal_get_query (e-cal.c:3844) ==23683== by 0xEC1C210: update_e_cal_view_for_client (e-cal-model.c:2066) ==23683== by 0xEC1C4D2: redo_queries (e-cal-model.c:2367) ==23683== by 0x1049348C: memo_shell_view_execute_search (e-memo-shell-view.c:157) ==23683== ==23683== 174 bytes in 3 blocks are definitely lost in loss record 21,312 of 26,937 ==23683== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==23683== by 0x3A4DC45784: g_malloc (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC5D2DD: g_strdup (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75721: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75481: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75C48: g_variant_get_va (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75E85: g_variant_get (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x6DA5E56: e_gdbus_cal_call_get_query_sync (e-gdbus-egdbuscal.c:4062) ==23683== by 0x6D86415: e_cal_get_query (e-cal.c:3844) ==23683== by 0xEC1C210: update_e_cal_view_for_client (e-cal-model.c:2066) ==23683== by 0xEC1C4D2: redo_queries (e-cal-model.c:2367) ==23683== by 0x10499B06: task_shell_view_execute_search (e-task-shell-view.c:270) ==23683== ==23683== 174 bytes in 3 blocks are definitely lost in loss record 21,313 of 26,937 ==23683== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==23683== by 0x3A4DC45784: g_malloc (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC5D2DD: g_strdup (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75721: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75481: ??? (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75C48: g_variant_get_va (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x3A4DC75E85: g_variant_get (in /lib64/libglib-2.0.so.0.2512.0) ==23683== by 0x6DA5E56: e_gdbus_cal_call_get_query_sync (e-gdbus-egdbuscal.c:4062) ==23683== by 0x6D86415: e_cal_get_query (e-cal.c:3844) ==23683== by 0xEC1C210: update_e_cal_view_for_client (e-cal-model.c:2066) ==23683== by 0xEC1C4D2: redo_queries (e-cal-model.c:2367) ==23683== by 0xEC7326D: gnome_calendar_set_search_query (gnome-cal.c:1196) ==23683==
Debugging symbols for GLib would be helpful here.
This may be a different trace, but perhaps related: ==6588== 1 bytes in 1 blocks are definitely lost in loss record 66 of 42,467 ==6588== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==6588== by 0x8802C80: g_malloc (gmem.c:134) ==6588== by 0x881B31D: g_strdup (gstrfuncs.c:101) ==6588== by 0x883546C: g_variant_valist_get (gvariant.c:3602) ==6588== by 0x88352F9: g_variant_valist_get (gvariant.c:3977) ==6588== by 0x8836158: g_variant_get_va (gvariant.c:4173) ==6588== by 0x88362A5: g_variant_get (gvariant.c:4125) ==6588== by 0x6DA7CCF: e_gdbus_cal_call_get_cal_address_sync (e-gdbus-egdbuscal.c:2050) ==6588== by 0x6D8D4FC: e_cal_get_cal_address (e-cal.c:1697) ==6588== by 0xF8E5197: itip_get_comp_attendee (itip-utils.c:205) ==6588== by 0xF90830B: event_editor_edit_comp (event-editor.c:634) ==6588== by 0xF895A35: e_calendar_view_open_event_with_flags (e-calendar-view.c:1550) ==6588==
commit id - ca7347eba74cedf787d83ad39f206f9f3ef5a0af . Fixes the leak at comment #2 and description of the bug + adds locks for the data cached ECal.