Bug 989219

Summary: [abrt] evolution-3.8.4-1.fc19: g_logv: Process /usr/bin/evolution was killed by signal 5 (SIGTRAP)
Product: [Fedora] Fedora Reporter: Brian J. Murrell <brian>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: brian, lucilanga, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:442d3817247d088ba79215b30314aed0a847194e
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 09:52:01 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
File: xsession_errors none

Description Brian J. Murrell 2013-07-28 13:30:28 UTC 
Version-Release number of selected component:
evolution-3.8.4-1.fc19

Additional info:
reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        evolution
crash_function: g_logv
executable:     /usr/bin/evolution
kernel:         3.9.9-302.fc19.x86_64
runlevel:       N 5
uid:            1001

Truncated backtrace:
Thread no. 1 (9 frames)
 #2 g_wakeup_new at /lib64/libglib-2.0.so.0
 #3 g_main_context_new at /lib64/libglib-2.0.so.0
 #4 async_closure_new at /lib64/libcamel-1.2.so.43
 #5 camel_service_connect_sync at /lib64/libcamel-1.2.so.43
 #6 imapx_refresh_info_sync at /lib64/libcamel-1.2.so.43
 #7 camel_folder_refresh_info_sync at /lib64/libcamel-1.2.so.43
 #8 refresh_folders_exec at /usr/lib64/evolution/3.8/libevolution-mail.so
 #9 mail_msg_proxy at /usr/lib64/evolution/3.8/libemail-engine.so
 #11 g_thread_proxy at /lib64/libglib-2.0.so.0
Comment 1 Brian J. Murrell 2013-07-28 13:30:33 UTC 
Created attachment 779338 [details]
File: backtrace
Comment 2 Brian J. Murrell 2013-07-28 13:30:36 UTC 
Created attachment 779339 [details]
File: cgroup
Comment 3 Brian J. Murrell 2013-07-28 13:30:39 UTC 
Created attachment 779340 [details]
File: core_backtrace
Comment 4 Brian J. Murrell 2013-07-28 13:30:42 UTC 
Created attachment 779341 [details]
File: dso_list
Comment 5 Brian J. Murrell 2013-07-28 13:30:47 UTC 
Created attachment 779342 [details]
File: environ
Comment 6 Brian J. Murrell 2013-07-28 13:30:50 UTC 
Created attachment 779343 [details]
File: limits
Comment 7 Brian J. Murrell 2013-07-28 13:30:53 UTC 
Created attachment 779344 [details]
File: maps
Comment 8 Brian J. Murrell 2013-07-28 13:30:56 UTC 
Created attachment 779345 [details]
File: open_fds
Comment 9 Brian J. Murrell 2013-07-28 13:30:59 UTC 
Created attachment 779346 [details]
File: proc_pid_status
Comment 10 Brian J. Murrell 2013-07-28 13:31:02 UTC 
Created attachment 779347 [details]
File: var_log_messages
Comment 11 Brian J. Murrell 2013-07-28 13:31:05 UTC 
Created attachment 779348 [details]
File: xsession_errors
Comment 12 Milan Crha 2013-07-29 05:20:23 UTC 
Thanks for a bug report. I see the evolution got out of file descriptors, it had opened 1024 files, and failed when it tried to create a new one, while the 1024 is the upper limit. Most of your opened files are sockets, thus it seems like something is leaking connections to a server.

Could you provide account types you use, please? You can see that in Edit->preferences->mail Accounts, the 'Type' column in the list of accounts. Also, I suppose you've got this crash after several hours of running evolution, right? I see in the log that you also updated evolution packages while you've left the old running. It's not a big problem, I only noticed it.
Comment 13 Brian J. Murrell 2013-07-31 14:24:46 UTC 
I have several impax accounts, a pop3 account (which I was using gssapi with[1]) and an ews account.

[1] The gssapi servers in our network are numerous and many of them seem to be quite flaky, failing gssapi authentication, etc. while others are not so many times an authentication to a pop3 could fail.  I wonder if it's those that are leaking since presumably gssapi authentication with servers that work is fairly well-trodden ground.
Comment 14 Milan Crha 2013-08-01 09:52:01 UTC 
Thanks for the update. I see the pop3 leaks the handle on failed authentication. it does it each time it tries to connect to the server and it fails. I'm moving this upstream, for better visibility. Please see [1] for any further updates.

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