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
Created attachment 779338 [details] File: backtrace
Created attachment 779339 [details] File: cgroup
Created attachment 779340 [details] File: core_backtrace
Created attachment 779341 [details] File: dso_list
Created attachment 779342 [details] File: environ
Created attachment 779343 [details] File: limits
Created attachment 779344 [details] File: maps
Created attachment 779345 [details] File: open_fds
Created attachment 779346 [details] File: proc_pid_status
Created attachment 779347 [details] File: var_log_messages
Created attachment 779348 [details] File: xsession_errors
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[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.
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