Version-Release number of selected component:
runlevel: N 5
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]
Created attachment 922013 [details]
Created attachment 922014 [details]
Created attachment 922015 [details]
Created attachment 922016 [details]
Created attachment 922017 [details]
Created attachment 922018 [details]
Created attachment 922019 [details]
Created attachment 922020 [details]
Created attachment 922021 [details]
Created attachment 922022 [details]
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.
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).