Bug 1124956

Summary: [abrt] evolution-data-server: strrchr(): evolution-calendar-factory killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Alex Chvatal <achvatal>
Component: evolution-data-serverAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: fabiano, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/9da3de26efe36d5aa71ef0c39fd257d9e76aefaa
Whiteboard: abrt_hash:9926144c2f186ab7555069986244ba1fc77efe46
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-31 08:13:56 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 Alex Chvatal 2014-07-30 17:41:51 UTC
Description of problem:
i ran into this problem after applying an update to an existing calendar event that would cancel the event

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: strrchr
executable:     /usr/libexec/evolution-calendar-factory
kernel:         3.15.5-200.mst.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 strrchr at ../sysdeps/x86_64/strrchr.S:32
 #1 caldav_generate_uri at e-cal-backend-caldav.c:1159
 #2 caldav_server_put_object at e-cal-backend-caldav.c:1903
 #3 do_remove_objects at e-cal-backend-caldav.c:4339
 #4 process_object at e-cal-backend-caldav.c:4532
 #5 do_receive_objects at e-cal-backend-caldav.c:4618
 #6 caldav_receive_objects at e-cal-backend-caldav.c:4715
 #7 cal_backend_receive_objects at e-cal-backend-sync.c:762
 #8 cal_backend_receive_objects_thread at e-cal-backend.c:2988
 #9 cal_backend_dispatch_thread at e-cal-backend.c:233

Comment 1 Alex Chvatal 2014-07-30 17:41:53 UTC
Created attachment 922648 [details]
File: backtrace

Comment 2 Alex Chvatal 2014-07-30 17:41:54 UTC
Created attachment 922649 [details]
File: cgroup

Comment 3 Alex Chvatal 2014-07-30 17:41:55 UTC
Created attachment 922650 [details]
File: core_backtrace

Comment 4 Alex Chvatal 2014-07-30 17:41:56 UTC
Created attachment 922651 [details]
File: dso_list

Comment 5 Alex Chvatal 2014-07-30 17:41:56 UTC
Created attachment 922652 [details]
File: environ

Comment 6 Alex Chvatal 2014-07-30 17:41:57 UTC
Created attachment 922653 [details]
File: exploitable

Comment 7 Alex Chvatal 2014-07-30 17:41:58 UTC
Created attachment 922654 [details]
File: limits

Comment 8 Alex Chvatal 2014-07-30 17:41:59 UTC
Created attachment 922655 [details]
File: maps

Comment 9 Alex Chvatal 2014-07-30 17:42:00 UTC
Created attachment 922656 [details]
File: open_fds

Comment 10 Alex Chvatal 2014-07-30 17:42:00 UTC
Created attachment 922657 [details]
File: proc_pid_status

Comment 11 Alex Chvatal 2014-07-30 17:42:01 UTC
Created attachment 922658 [details]
File: var_log_messages

Comment 12 Milan Crha 2014-07-31 08:13:56 UTC
Thanks for a bug report. I see from the backtrace that the locally stored component had/has missing information about its origin, which looks odd, because locally stored components should have this information available.

I moved this upstream as [1]. Please see [1] for any further updates. If possible, please CC yourself there, in case upstream developers will have additional questions.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=734025