Bug 1009395

Summary: [abrt] evolution-data-server-3.8.5-4.fc19: __memset_sse2: Process /usr/libexec/evolution-calendar-factory was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Reinout van Schouwen <reinouts>
Component: evolution-data-serverAssignee: Matthew Barnes <mbarnes>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: mbarnes, mcrha, reinouts
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:113272c03973fa95f36b3996561a48a001858bec
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-12 07:01:27 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

Description Reinout van Schouwen 2013-09-18 10:56:37 UTC 
Description of problem:
Imported an ics attachment received by mail.

Version-Release number of selected component:
evolution-data-server-3.8.5-4.fc19

Additional info:
reporter:       libreport-2.1.6
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-calendar-factory
crash_function: __memset_sse2
executable:     /usr/libexec/evolution-calendar-factory
kernel:         3.10.10-200.fc19.x86_64
runlevel:       N 5
uid:            500

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 __memset_sse2 at ../sysdeps/x86_64/memset.S:334
 #1 memset at /usr/include/bits/string3.h:84
 #2 e_memchunk_alloc0 at e-memory.c:151
 #3 e_sexp_result_new at e-sexp.c:191
 #4 e_sexp_term_eval at e-sexp.c:751
 #7 e_sexp_eval at e-sexp.c:1698
 #8 e_cal_backend_sexp_match_comp at e-cal-backend-sexp.c:1254
 #9 e_data_cal_view_component_matches at e-data-cal-view.c:966
 #10 e_cal_backend_notify_component_created at e-cal-backend.c:1750
 #11 put_server_comp_to_cache at e-cal-backend-caldav.c:3159
Comment 1 Reinout van Schouwen 2013-09-18 10:56:40 UTC 
Created attachment 799317 [details]
File: backtrace
Comment 2 Reinout van Schouwen 2013-09-18 10:56:44 UTC 
Created attachment 799318 [details]
File: cgroup
Comment 3 Reinout van Schouwen 2013-09-18 10:56:47 UTC 
Created attachment 799319 [details]
File: core_backtrace
Comment 4 Reinout van Schouwen 2013-09-18 10:56:50 UTC 
Created attachment 799320 [details]
File: dso_list
Comment 5 Reinout van Schouwen 2013-09-18 10:56:53 UTC 
Created attachment 799321 [details]
File: environ
Comment 6 Reinout van Schouwen 2013-09-18 10:56:56 UTC 
Created attachment 799322 [details]
File: exploitable
Comment 7 Reinout van Schouwen 2013-09-18 10:56:58 UTC 
Created attachment 799323 [details]
File: limits
Comment 8 Reinout van Schouwen 2013-09-18 10:57:02 UTC 
Created attachment 799324 [details]
File: maps
Comment 9 Reinout van Schouwen 2013-09-18 10:57:05 UTC 
Created attachment 799325 [details]
File: open_fds
Comment 10 Reinout van Schouwen 2013-09-18 10:57:07 UTC 
Created attachment 799326 [details]
File: proc_pid_status
Comment 11 Milan Crha 2013-09-18 17:45:14 UTC 
Thanks for a bug report. I see that the Google backend was asked for a component, which it did not find, thus it asked the Google server and it found it, and while the CalDAV backend tried to put the just downloaded component into its local cache a crash happened. Are you able to reproduce the crash with the ics attachment email consistently? If I understand the consequences correctly, then you just selected the message in evolution, which recognized an iCalendar attachment, and it tried to find it in your calendars.
Comment 12 Reinout van Schouwen 2014-06-11 21:27:05 UTC 
I am sorry, I am using a newer version nowadays and don't recall which email caused the crash.
Comment 13 Milan Crha 2014-06-12 07:01:27 UTC 
Thanks for an update. I realized there had been filled another similar bug report meanwhile, which was moved upstream, thus let's move there too.

*** This bug has been marked as a duplicate of bug 1013213 ***