Bug 1220320

Summary: [abrt] evolution-data-server: strlen(): evolution-addressbook-factory killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Alexander Kurtakov <akurtako>
Component: evolution-data-serverAssignee: Milan Crha <mcrha>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: mbarnes, mcrha, ssahani, wicked1099
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/6411c7a16191accbfcea0d7371528d823472083e
Whiteboard: abrt_hash:71fe61df9a1c7e353c369a35bd47af02712350c6
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-14 14:22:33 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: limits
none
File: maps
none
File: mountinfo
none
File: namespaces
none
File: open_fds
none
File: proc_pid_status none

Description Alexander Kurtakov 2015-05-11 10:09:45 UTC 
Version-Release number of selected component:
evolution-data-server-3.16.1-1.fc22

Additional info:
reporter:       libreport-2.5.1
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-addressbook-factory
crash_function: strlen
executable:     /usr/libexec/evolution-addressbook-factory
global_pid:     2400
kernel:         4.0.0-0.rc5.git4.1.fc22.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000
var_log_messages: [System Logs]:\n-- Logs begin at Tue 2015-03-10 00:36:57 EET, end at Fri 2015-04-24 09:19:42 EEST. --

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 strlen at ../sysdeps/x86_64/strlen.S:106
 #1 g_strdup at gstrfuncs.c:355
 #2 schedule_call_in_idle at gdbusnamewatching.c:192
 #3 do_call at gdbusnamewatching.c:214
 #4 ffi_call_unix64 at ../src/x86/unix64.S:76
 #5 ffi_call at ../src/x86/ffi64.c:525
 #6 g_cclosure_marshal_generic at gclosure.c:1448
 #11 emit_closed_in_idle at gdbusconnection.c:1386
 #16 source_registry_object_manager_thread at e-source-registry.c:1160
 #17 g_thread_proxy at gthread.c:764
Comment 1 Alexander Kurtakov 2015-05-11 10:09:49 UTC 
Created attachment 1024171 [details]
File: backtrace
Comment 2 Alexander Kurtakov 2015-05-11 10:09:51 UTC 
Created attachment 1024172 [details]
File: cgroup
Comment 3 Alexander Kurtakov 2015-05-11 10:09:52 UTC 
Created attachment 1024173 [details]
File: core_backtrace
Comment 4 Alexander Kurtakov 2015-05-11 10:09:54 UTC 
Created attachment 1024174 [details]
File: dso_list
Comment 5 Alexander Kurtakov 2015-05-11 10:09:56 UTC 
Created attachment 1024175 [details]
File: environ
Comment 6 Alexander Kurtakov 2015-05-11 10:09:58 UTC 
Created attachment 1024176 [details]
File: limits
Comment 7 Alexander Kurtakov 2015-05-11 10:10:01 UTC 
Created attachment 1024177 [details]
File: maps
Comment 8 Alexander Kurtakov 2015-05-11 10:10:02 UTC 
Created attachment 1024178 [details]
File: mountinfo
Comment 9 Alexander Kurtakov 2015-05-11 10:10:04 UTC 
Created attachment 1024179 [details]
File: namespaces
Comment 10 Alexander Kurtakov 2015-05-11 10:10:05 UTC 
Created attachment 1024180 [details]
File: open_fds
Comment 11 Alexander Kurtakov 2015-05-11 10:10:06 UTC 
Created attachment 1024181 [details]
File: proc_pid_status
Comment 12 Milan Crha 2015-05-12 06:05:01 UTC 
Thanks for a bug report. This crashed in a GDBus code, thus part of glib2. By any chance, do you have any steps or a reproducer for the crash, please?
Comment 13 Alexander Kurtakov 2015-05-12 06:29:09 UTC 
No, I have google calendar added and when opening some notifications this crash happens but not always. Not sure what is the connection nor how to reproduce. Feel free to close it if the backtrace is not valuable hint.
Comment 14 Milan Crha 2015-05-14 14:22:33 UTC 
Okay. The backtrace is pretty clean, the crash happened in a thread, in a GDBus code, which could, or not, be due to some oddities in the evolution-data-server code. Let's reopen if there'll be more cases.