Bug 1014321

Summary: [abrt] evolution-3.8.5-2.fc19: g_data_set_internal: Process /usr/bin/evolution was killed by signal 6 (SIGABRT)
Product: [Fedora] Fedora Reporter: Sergio Basto <sergio>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: lucilanga, mbarnes, mcrha, sergio
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:21746effdfa6cdfdc269543af10246f1da36b05e
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-08 10:43:08 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: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Sergio Basto 2013-10-01 17:34:27 UTC 
Version-Release number of selected component:
evolution-3.8.5-2.fc19

Additional info:
reporter:       libreport-2.1.7
backtrace_rating: 4
cmdline:        /usr/bin/evolution
crash_function: g_data_set_internal
executable:     /usr/bin/evolution
kernel:         3.10.11-200.fc19.x86_64
runlevel:       N 5
type:           CCpp
uid:            500

Truncated backtrace:
Thread no. 1 (10 frames)
 #6 g_data_set_internal at gdataset.c:383
 #7 g_datalist_id_set_data_full at gdataset.c:674
 #8 g_object_notify_queue_thaw at gobject.c:287
 #10 g_object_new_valist at gobject.c:1836
 #12 g_object_bind_property_full at gbinding.c:936
 #13 g_object_bind_property at gbinding.c:1010
 #14 settings_mail_formatter_constructed at e-settings-mail-formatter.c:143
 #16 g_object_new_valist at gobject.c:1836
 #18 extensible_load_extension at e-extensible.c:97
 #19 e_type_traverse at e-module.c:362
Comment 1 Sergio Basto 2013-10-01 17:34:31 UTC 
Created attachment 806110 [details]
File: backtrace
Comment 2 Sergio Basto 2013-10-01 17:34:38 UTC 
Created attachment 806111 [details]
File: cgroup
Comment 3 Sergio Basto 2013-10-01 17:34:41 UTC 
Created attachment 806112 [details]
File: core_backtrace
Comment 4 Sergio Basto 2013-10-01 17:34:45 UTC 
Created attachment 806113 [details]
File: dso_list
Comment 5 Sergio Basto 2013-10-01 17:34:49 UTC 
Created attachment 806114 [details]
File: environ
Comment 6 Sergio Basto 2013-10-01 17:34:53 UTC 
Created attachment 806115 [details]
File: limits
Comment 7 Sergio Basto 2013-10-01 17:34:58 UTC 
Created attachment 806116 [details]
File: maps
Comment 8 Sergio Basto 2013-10-01 17:35:02 UTC 
Created attachment 806117 [details]
File: open_fds
Comment 9 Sergio Basto 2013-10-01 17:35:06 UTC 
Created attachment 806118 [details]
File: proc_pid_status
Comment 10 Sergio Basto 2013-10-01 17:35:11 UTC 
Created attachment 806119 [details]
File: var_log_messages
Comment 11 Milan Crha 2013-10-02 09:55:34 UTC 
Thanks for a bug report. I see the malloc recognized a "free(): invalid pointer" error, which means that there happened a memory corruption (the application accessed memory it might not, most likely). Such errors can be recognized in various occasions, not necessarily immediately after such write happened, thus it's quite hard to find out where the issue happened, without any hints. Do you have idea what you did before the crash, please? Any detail may help to identify the cause of the issue.
Comment 12 Sergio Basto 2013-10-17 17:35:55 UTC 
Hi, 
Sorry for delay , but wasn't a easy question , I find out all my problems came from suspend laptop with evolution running , when I resume computer all things strange happens .
Sometimes inbox don't display any message, says empty folder ... 
Recently filter instead delete and copy to folder , moves the message to folder , and disappears the deletes messages in inbox .

Scroll stop work correctly since I upgrade to F19 , I use evolution in a kde. 

and I have some messages about old keyring , how I update to new keyring ...
Comment 13 Milan Crha 2013-11-05 15:26:23 UTC 
Please see bug #1024314 for the suspend/resume issue, I might cause part of your problems within evolution-data-server-3.8.5-5 update for Fedora 19, which I reverted in 3.8.5-6 release (will reach updates testing soon).

I cannot tell much about the last two things, they seem to be general system issues (I also see nonworking touchpad scroll in some environments, for which I would blame gtk3; the keyring issue is new to me, I did not notice any comment on it yet).

Are you on evolution-data-server-3.8.5-5? Will update to evolution-data-server-3.8.5-6 help anyhow?
Comment 14 Sergio Basto 2013-11-05 16:55:02 UTC 
Hi , many thanks for all the tips .

yes, I use evolution-data-server-3.8.5-5.fc19.x86_64 

rpm -q evolution-data-server 
evolution-data-server-3.8.5-5.fc19.x86_64

I already migrate my gnome-keyring :
http://unix.stackexchange.com/questions/20451/gnome-keyring-daemon-couldnt-allocate-secure-memory/96902#96902 , and all gnome things works better.

I will test new version , for the record , this abrt crash, seems seasonal, and many times abrt say that backtrace is unrecoverable. 
Note I have emails since 2004, just check recently . 

Best regards,
Comment 15 Milan Crha 2013-11-05 17:39:17 UTC 
Thanks for the update. What do you mean with 'seasonal', please? Is it that you can reproduce this on will, after certain set of steps?
Comment 16 Sergio Basto 2013-11-06 01:01:50 UTC 
seasonal , just happen in some times of the year :) like in spring , during a week or two happens 10 times, after that 2 months without the problem . and No I can't reproduce it , is fedora updates ...

Thanks.
Comment 17 Milan Crha 2013-11-08 10:43:08 UTC 
Aah, I see. :) Please try with 3.8.5-6, as I mentioned above, just in case. I'm closing this for now, because I do not see much from the backtrace, but feel free to reopen, update this bug or fill a new, if it happens again for you (as a memory corruption bug, it can reveal itself anywhere in the code, thus the pairing with this bug will be surely unclear).