Version-Release number of selected component: evolution-data-server-3.10.4-3.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: /usr/libexec/evolution-calendar-factory crash_function: e_cal_component_get_uid executable: /usr/libexec/evolution-calendar-factory kernel: 3.14.8-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (6 frames) #0 e_cal_component_get_uid at e-cal-component.c:1481 #1 match_object_sexp_to_component at e-cal-backend-file.c:1591 #2 g_list_foreach at glist.c:949 #3 e_cal_backend_file_start_view at e-cal-backend-file.c:1906 #4 calview_start_thread at e-data-cal-view.c:174 #5 g_thread_proxy at gthread.c:798
Created attachment 922012 [details] File: backtrace
Created attachment 922013 [details] File: cgroup
Created attachment 922014 [details] File: core_backtrace
Created attachment 922015 [details] File: dso_list
Created attachment 922016 [details] File: environ
Created attachment 922017 [details] File: exploitable
Created attachment 922018 [details] File: limits
Created attachment 922019 [details] File: maps
Created attachment 922020 [details] File: open_fds
Created attachment 922021 [details] File: proc_pid_status
Created attachment 922022 [details] File: var_log_messages
Thanks for abug report. I do not see much from the backtrace, unfortunately, just that one of your local calendars was updating content of one of the views, where it used some calendar component which was already freed. Do you have any steps for a reproducer, please?
I am sorry. I don't have any steps to reproduce this problem. Evolution works nicely on my machine most of the time, and this a one of those rare Abrt popups that I got. I don't know what triggered it. I was hoping that the trace would contain enough information to help you. -> Feel free to close this bug if it does not help. kind regards, Egon
Thanks for the update. I'm closing this for now, it can also be an issue of incorrect memory write, some sort of use-after-free from a different calendar backend, overwriting memory which it should not write to. That's only a wild guess, no prove from the backtrace. Feel free to reopen, in case you'll face this again, the best with a description what was happening when the crash happened (a general rule, though).