Red Hat Bugzilla – Bug 989219
[abrt] evolution-3.8.4-1.fc19: g_logv: Process /usr/bin/evolution was killed by signal 5 (SIGTRAP)
Last modified: 2013-08-01 05:52:01 EDT
Version-Release number of selected component:
runlevel: N 5
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
Created attachment 779338 [details]
Created attachment 779339 [details]
Created attachment 779340 [details]
Created attachment 779341 [details]
Created attachment 779342 [details]
Created attachment 779343 [details]
Created attachment 779344 [details]
Created attachment 779345 [details]
Created attachment 779346 [details]
Created attachment 779347 [details]
Created attachment 779348 [details]
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.
I have several impax accounts, a pop3 account (which I was using gssapi with) and an ews account.
 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.
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  for any further updates.