Bug 1082733

Summary: [abrt] evolution-data-server: magazine_cache_trim(): evolution-addressbook-factory killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Cezary Zemis <cezary.zemis>
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: cezary.zemis, fabiano, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/e77ad565413743546ba8ad640e5deb2933868363
Whiteboard: abrt_hash:4b418ef958c96a0011f31ce728393308e494dd04
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-03 10:30:34 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 Cezary Zemis 2014-03-31 17:42:45 UTC 
Description of problem:
while updating a contact

Version-Release number of selected component:
evolution-data-server-3.10.4-3.fc20

Additional info:
reporter:       libreport-2.2.0
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-addressbook-factory
crash_function: magazine_cache_trim
executable:     /usr/libexec/evolution-addressbook-factory
kernel:         3.13.6-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1001

Truncated backtrace:
Thread no. 1 (10 frames)
 #2 magazine_cache_trim at gslice.c:685
 #3 magazine_cache_push_magazine at gslice.c:716
 #4 thread_memory_magazine2_unload at gslice.c:815
 #5 g_slice_free_chain_with_offset at gslice.c:1186
 #6 g_list_free at glist.c:152
 #7 g_list_free_full at glist.c:188
 #8 vcard_finalize at e-vcard.c:164
 #10 e_book_backend_modify_contacts_finish at e-book-backend.c:1805
 #11 data_book_complete_modify_contacts_cb at e-data-book.c:881
 #12 g_simple_async_result_complete at gsimpleasyncresult.c:777
Comment 1 Cezary Zemis 2014-03-31 17:42:53 UTC 
Created attachment 880969 [details]
File: backtrace
Comment 2 Cezary Zemis 2014-03-31 17:42:55 UTC 
Created attachment 880972 [details]
File: cgroup
Comment 3 Cezary Zemis 2014-03-31 17:42:57 UTC 
Created attachment 880973 [details]
File: core_backtrace
Comment 4 Cezary Zemis 2014-03-31 17:43:00 UTC 
Created attachment 880975 [details]
File: dso_list
Comment 5 Cezary Zemis 2014-03-31 17:43:02 UTC 
Created attachment 880976 [details]
File: environ
Comment 6 Cezary Zemis 2014-03-31 17:43:03 UTC 
Created attachment 880977 [details]
File: exploitable
Comment 7 Cezary Zemis 2014-03-31 17:43:06 UTC 
Created attachment 880978 [details]
File: limits
Comment 8 Cezary Zemis 2014-03-31 17:43:08 UTC 
Created attachment 880979 [details]
File: maps
Comment 9 Cezary Zemis 2014-03-31 17:43:10 UTC 
Created attachment 880980 [details]
File: open_fds
Comment 10 Cezary Zemis 2014-03-31 17:43:13 UTC 
Created attachment 880981 [details]
File: proc_pid_status
Comment 11 Cezary Zemis 2014-03-31 17:43:15 UTC 
Created attachment 880982 [details]
File: var_log_messages
Comment 12 Milan Crha 2014-04-02 08:03:25 UTC 
Thanks for a bug report. I see from the backtrace that this crashed after the modification of a contact had been over, when freeing the actual object. It seems like some part of the code already freed the memory which was about to be freed.

Could you provide some more information, please? It would help to identify the issue, when you'll answer the following questions:
a) what was the addressbook type where the change of the contact was made?
   (On This Computer, On The Web, LDAP, ....)
b) do you remember what exact change was made to the contact, please? It can
   be that certain changes don't exhibit the issue.

Thanks in advance.
Comment 13 Cezary Zemis 2014-04-02 08:26:56 UTC 
I can confirm the record was actually changed.

It was Google's addressbook.

I was adding a postal address to an existing contact. The contact probably had Google+ account (I could see their avatar on my Android, and I hadn't added it manually) if this matters. 

The issue is not reproducible.
Comment 14 Milan Crha 2014-04-03 10:30:34 UTC 
Thanks for the update. The symptoms are basically the same as in an upstream bug report [1], thus I'm closing this in a favour of it. Please see it for any further changes.

My personal opinion is that some change in the contact causes memory corruption (like if a process writes to an already freed memory, or some memory is freed twice, or ...), which can exhibit in many ways. As the symptoms of "updating a contact in a Google book" are the same, I'd say this is the same issue. The clue of changing particular field is helpful.

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