Bug 1124130

Summary: [abrt] evolution-data-server: e_cal_component_get_uid(): evolution-calendar-factory killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Egon Kastelijn <redhat2>
Component: evolution-data-serverAssignee: Matthew Barnes <mbarnes>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: fabiano, mbarnes, mcrha, redhat2
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/19fb16409a5ee3fcfa8375815020974d7aff88ae
Whiteboard: abrt_hash:79b664bc67614ebf3cdd80d8a984396064cd6d54
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-01 08:20:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Egon Kastelijn 2014-07-29 03:46:53 UTC 
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
Comment 1 Egon Kastelijn 2014-07-29 03:46:56 UTC 
Created attachment 922012 [details]
File: backtrace
Comment 2 Egon Kastelijn 2014-07-29 03:46:58 UTC 
Created attachment 922013 [details]
File: cgroup
Comment 3 Egon Kastelijn 2014-07-29 03:47:01 UTC 
Created attachment 922014 [details]
File: core_backtrace
Comment 4 Egon Kastelijn 2014-07-29 03:47:02 UTC 
Created attachment 922015 [details]
File: dso_list
Comment 5 Egon Kastelijn 2014-07-29 03:47:03 UTC 
Created attachment 922016 [details]
File: environ
Comment 6 Egon Kastelijn 2014-07-29 03:47:04 UTC 
Created attachment 922017 [details]
File: exploitable
Comment 7 Egon Kastelijn 2014-07-29 03:47:06 UTC 
Created attachment 922018 [details]
File: limits
Comment 8 Egon Kastelijn 2014-07-29 03:47:10 UTC 
Created attachment 922019 [details]
File: maps
Comment 9 Egon Kastelijn 2014-07-29 03:47:11 UTC 
Created attachment 922020 [details]
File: open_fds
Comment 10 Egon Kastelijn 2014-07-29 03:47:12 UTC 
Created attachment 922021 [details]
File: proc_pid_status
Comment 11 Egon Kastelijn 2014-07-29 03:47:13 UTC 
Created attachment 922022 [details]
File: var_log_messages
Comment 12 Milan Crha 2014-07-29 08:12:42 UTC 
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?
Comment 13 Egon Kastelijn 2014-08-03 11:49:13 UTC 
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
Comment 14 Milan Crha 2014-09-01 08:20:20 UTC 
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).