After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 655272 - IMAPX: Leaking file descriptors from open pipes (probably CamelMsgPorts)
IMAPX: Leaking file descriptors from open pipes (probably CamelMsgPorts)
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.2.x (obsolete)
Other Linux
: Normal major
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 630124 655303 656319 657300 659996 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-07-25 15:23 UTC by Stephan Haller
Modified: 2015-08-26 08:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed eds patch (15.59 KB, patch)
2011-08-01 12:54 UTC, Milan Crha
committed Details | Review

Description Stephan Haller 2011-07-25 15:23:07 UTC
Hi,

since upgrading evolution to 3.0.2 I have problems that evolution keeps crashing because of "too many files" when it is running 3+ days non-stop.

I have set up an imapx account which connects an Exchange IMAP server. Additionally I have set up around 10 filters for incoming mails. Now evolution crashes with "too many files". I cannot remember that evolution 2.32 was crashing - maybe after a month running non-stop ;)

Most open file are "pipes".

----
shaller@shaller ~ $ ls -l1 /proc/4230/fd | grep pipe\: | wc -l
986
----

The last error message at standard out are:

----
[...]
(evolution:4230): camel-WARNING **: CamelIMAPXStore::noop_sync() reported failure without setting its GError
[New Thread 0x7fffcbd05700 (LWP 8936)]
[New Thread 0x7fffcffa6700 (LWP 8938)]
[Thread 0x7fffcffa6700 (LWP 8938) exited]
[New Thread 0x7fffcffa6700 (LWP 8939)]
[Thread 0x7fffcbd05700 (LWP 8936) exited]
[Thread 0x7fffc8ff3700 (LWP 8929) exited]
[Thread 0x7fffcffa6700 (LWP 8939) exited]
[New Thread 0x7fffcffa6700 (LWP 9355)]
[Thread 0x7fffcffa6700 (LWP 9355) exited]
[New Thread 0x7fffcffa6700 (LWP 9440)]

(evolution:4230): camel-WARNING **: CamelIMAPXStore::noop_sync() reported failure without setting its GError
[New Thread 0x7fffc8ff3700 (LWP 9441)]
[New Thread 0x7fffcbd05700 (LWP 9442)]
[Thread 0x7fffcbd05700 (LWP 9442) exited]
[New Thread 0x7fffcbd05700 (LWP 9443)]
[Thread 0x7fffc8ff3700 (LWP 9441) exited]
[Thread 0x7fffcffa6700 (LWP 9440) exited]
[Thread 0x7fffcbd05700 (LWP 9443) exited]
[New Thread 0x7fffcbd05700 (LWP 9490)]
[Thread 0x7fffcbd05700 (LWP 9490) exited]
[New Thread 0x7fffcbd05700 (LWP 9534)]

(evolution:4230): camel-WARNING **: CamelIMAPXStore::noop_sync() reported failure without setting its GError
[New Thread 0x7fffcffa6700 (LWP 9535)]
[New Thread 0x7fffc8ff3700 (LWP 9536)]
[Thread 0x7fffc8ff3700 (LWP 9536) exited]
[New Thread 0x7fffc8ff3700 (LWP 9537)]
[Thread 0x7fffcffa6700 (LWP 9535) exited]
[Thread 0x7fffcbd05700 (LWP 9534) exited]
[Thread 0x7fffc8ff3700 (LWP 9537) exited]
[New Thread 0x7fffc8ff3700 (LWP 9575)]
[Thread 0x7fffc8ff3700 (LWP 9575) exited]
[New Thread 0x7fffc8ff3700 (LWP 9667)]

(evolution:4230): camel-WARNING **: CamelIMAPXStore::noop_sync() reported failure without setting its GError
[New Thread 0x7fffcbd05700 (LWP 9668)]
[New Thread 0x7fffcffa6700 (LWP 9669)]
[Thread 0x7fffcffa6700 (LWP 9669) exited]
[New Thread 0x7fffcffa6700 (LWP 9670)]
[New Thread 0x7fffc3fff700 (LWP 9671)]
[New Thread 0x7fffd19d7700 (LWP 9672)]
[New Thread 0x7fffd0fa8700 (LWP 9673)]
[Thread 0x7fffd0fa8700 (LWP 9673) exited]
[New Thread 0x7fffd0fa8700 (LWP 9674)]
[Thread 0x7fffd0fa8700 (LWP 9674) exited]
[New Thread 0x7fffd0fa8700 (LWP 9675)]

(evolution:4230): camel-CRITICAL **: camel_stream_write_to_stream: assertion `CAMEL_IS_STREAM (output_stream)' failed

(evolution:4230): camel-WARNING **: CamelIMAPXFolder::get_message_sync() reported failure without setting its GError

(evolution:4230): e-data-server-WARNING **: Error in execution: Nachricht konnte nicht abgerufen werden
I/O error : Too many open files
I/O error : Too many open files
I/O warning : failed to load external entity "/home/shaller/.config/evolution/mail/views/current_view-imapx:__Stephan_20Haller@172.16.11.44_INBOX.xml"

GLib-ERROR **: Cannot create pipe main loop wake-up: Zu viele offene Dateien

aborting...

Program received signal SIGABRT, Aborted.
----

The last time I started evolution in gdb to get a backtrace and an overview about all running threads. I hope it is useful:

----
(gdb) bt
  • #0 raise
    from /lib64/libc.so.6
  • #1 abort
    from /lib64/libc.so.6
  • #2 g_logv
    from /usr/lib64/libglib-2.0.so.0
  • #3 g_log
    from /usr/lib64/libglib-2.0.so.0
  • #4 g_main_context_init_pipe
    from /usr/lib64/libglib-2.0.so.0
  • #5 g_main_context_new
    from /usr/lib64/libglib-2.0.so.0
  • #6 g_dbus_connection_send_message_with_reply_sync
    from /usr/lib64/libgio-2.0.so.0
  • #7 g_dbus_connection_call_sync
    from /usr/lib64/libgio-2.0.so.0
  • #8 g_dbus_proxy_call_sync
    from /usr/lib64/libgio-2.0.so.0
  • #9 notify_notification_show
    from /usr/lib64/libnotify.so.4
  • #10 notification_callback
    from /usr/lib64/evolution/3.0/plugins/liborg-gnome-mail-notification.so
  • #11 g_timeout_dispatch
    from /usr/lib64/libglib-2.0.so.0
  • #12 g_main_context_dispatch
    from /usr/lib64/libglib-2.0.so.0
  • #13 g_main_context_iterate
    from /usr/lib64/libglib-2.0.so.0
  • #14 g_main_loop_run
    from /usr/lib64/libglib-2.0.so.0
  • #15 gtk_main
    from /usr/lib64/libgtk-3.so.0
  • #16 main
  2634 Thread 0x7fffd0fa8700 (LWP 9675)  0x00007ffff5e94cb3 in poll () from /lib64/libc.so.6
  2631 Thread 0x7fffd19d7700 (LWP 9672)  0x00007ffff6451b4d in nanosleep () from /lib64/libpthread.so.0
  2630 Thread 0x7fffc3fff700 (LWP 9671)  0x00007ffff644e81b in pthread_cond_timedwait () from /lib64/libpthread.so.0
  2629 Thread 0x7fffcffa6700 (LWP 9670)  0x00007ffff5e94cb3 in poll () from /lib64/libc.so.6
  2627 Thread 0x7fffcbd05700 (LWP 9668)  0x00007ffff644e81b in pthread_cond_timedwait () from /lib64/libpthread.so.0
  2626 Thread 0x7fffc8ff3700 (LWP 9667)  0x00007ffff644e49c in pthread_cond_wait () from /lib64/libpthread.so.0
  2125 Thread 0x7fffd07a7700 (LWP 13476)  0x00007ffff5e94cb3 in poll () from /lib64/libc.so.6
  2 Thread 0x7fffe3234700 (LWP 4233)  0x00007ffff5e94cb3 in poll () from /lib64/libc.so.6
* 1 Thread 0x7ffff7f99900 (LWP 4230)  0x00007ffff5dfffe5 in raise () from /lib64/libc.so.6
----

If you need more information I try to provide them. But in some cases it needs around three days to wait for evolution to crash :(

Regards,
Stephan
Comment 1 Matthew Barnes 2011-07-25 15:34:00 UTC
Confirming, I've seen this myself.
Comment 2 Akhil Laddha 2011-07-26 03:44:25 UTC
can be related to bug 630124
Comment 3 Milan Crha 2011-07-26 11:09:59 UTC
Similar downstream bug report from 3.0.2 exposing a crash on quit:
https://bugzilla.redhat.com/show_bug.cgi?id=724947

Thread 1 (Thread 0xb7744890 (LWP 14348))

  • #0 __kernel_vsyscall
  • #1 __GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #2 __GI_abort
    at abort.c line 93
  • #3 g_logv
  • #4 g_log
    at gmessages.c line 577
  • #5 g_main_context_init_pipe
    at gmain.c line 530
  • #6 g_main_context_init_pipe
    at gmain.c line 520
  • #7 g_main_context_new
    at gmain.c line 626
  • #8 g_dbus_connection_send_message_with_reply_sync
    at gdbusconnection.c line 2003
  • #9 g_dbus_connection_call_sync
    at gdbusconnection.c line 5316
  • #10 g_dbus_proxy_call_sync
    at gdbusproxy.c line 2477
  • #11 e_gdbus_book_call_close_sync
    at e-gdbus-egdbusbook.c line 2570
  • #12 gdbus_book_disconnect
    at e-book.c line 155
  • #13 e_book_dispose
    at e-book.c line 169
  • #14 g_object_unref
    at gobject.c line 2697
  • #15 g_hash_table_remove_all_nodes
    at ghash.c line 492
  • #16 g_hash_table_remove_all
    at ghash.c line 1167
  • #17 g_hash_table_destroy
    at ghash.c line 874
  • #18 emu_free_mail_cache
    at em-utils.c line 2110
  • #19 mail_backend_ready_to_quit
    at e-mail-backend.c line 225
  • #20 mail_backend_prepare_for_quit_cb
    at e-mail-backend.c line 277
  • #21 g_cclosure_marshal_VOID__OBJECT
    at gmarshal.c line 638
  • #22 g_closure_invoke
    at gclosure.c line 767
  • #23 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #24 g_signal_emit_valist
    at gsignal.c line 2983
  • #25 g_signal_emit
    at gsignal.c line 3040
  • #26 shell_prepare_for_quit
    at e-shell.c line 382
  • #27 shell_prepare_for_quit
    at e-shell.c line 365
  • #28 e_shell_quit
    at e-shell.c line 2003
  • #29 action_quit_cb
    at e-shell-window-actions.c line 1013

Comment 4 Milan Crha 2011-08-01 12:54:41 UTC
Created attachment 192979 [details] [review]
proposed eds patch

for evolution-data-server;

This is most common part where CamelMsgPort-s are leaked in IMAPx and one in camel_folder_get_message_sync(), because each camel_operation_push_message() also references itself, which is kind of circular dependency on the object, which is never good, but that's something I do not want to judge here, because I do not understand the reason why Matthew did it this way.

I neither understand IMAPx code enough, thus I want a review from Chen here, as he things IMAPx is finished, but some parts aren't completed, from my point of view. For example jobs which are in a queue, are they ever freed? I do not see the place, but because I do not understand the code enough, then I do not want to break things I do not understand. Not this time :)
Comment 5 Milan Crha 2011-08-01 13:10:39 UTC
I also did a commit 8c351c1 in evolution master (3.1.5+) for a leak I found during this bug investigation.
Comment 6 Akhil Laddha 2011-08-11 05:04:09 UTC
*** Bug 656319 has been marked as a duplicate of this bug. ***
Comment 7 Milan Crha 2011-08-17 13:03:23 UTC
Created commit c597c9e in eds master (3.1.90+)
Comment 8 Milan Crha 2011-08-31 09:03:43 UTC
*** Bug 657300 has been marked as a duplicate of this bug. ***
Comment 9 Akhil Laddha 2011-09-08 06:30:09 UTC
*** Bug 655303 has been marked as a duplicate of this bug. ***
Comment 10 Akhil Laddha 2011-09-25 06:13:37 UTC
*** Bug 659996 has been marked as a duplicate of this bug. ***
Comment 11 Milan Crha 2015-08-26 08:07:19 UTC
*** Bug 630124 has been marked as a duplicate of this bug. ***