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 723594 - evolution hangs forever (dead lock ?) when connecting to a different network (and being allocated a different IP)
evolution hangs forever (dead lock ?) when connecting to a different network ...
Status: RESOLVED DUPLICATE of bug 702709
Product: evolution
Classification: Applications
Component: general
3.10.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2014-02-04 08:43 UTC by Mildred
Modified: 2014-03-26 08:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshoot describing the problem (225.69 KB, image/png)
2014-02-04 08:45 UTC, Mildred
Details

Description Mildred 2014-02-04 08:43:18 UTC
Very often, especially when I'm connecting my laptop in a new network (home network vs work network), evolution hangs by having many background operations that are stuck. See attached screnshoot. If I start a network operation, it is queued and never completes. Aborting the operation cause another operation called "Canceling ...", and it is never aborted. Closing evolution is impossible.

A summary of the processes having "evolution" in their argument list (ps fux | grep evolution):

mildred   1564  0.0  0.0 649632  8228 ?        Ssl  Feb03   0:00 gnome-session
mildred   1738  1.5  2.6 2171040 435028 ?      Sl   Feb03  20:18  \_ /usr/bin/gnome-shell
mildred   2520  0.7  0.8 4610456 144096 ?      Sl   Feb03   4:58  |   \_ evolution
mildred   1942  0.0  0.1 877708 29320 ?        Sl   Feb03   0:00  \_ /usr/libexec/evolution/3.10/evolution-alarm-notify
mildred   2250  0.0  0.2 1422748 42948 ?       Sl   Feb03   0:00 /usr/libexec/evolution-addressbook-factory
mildred   2227  1.3  0.5 1724564 91820 ?       Sl   Feb03  17:11 /usr/libexec/evolution-calendar-factory
mildred   1825  0.0  0.1 1112532 23392 ?       SLl  Feb03   0:44 /usr/libexec/evolution-source-registry

Stack trace of "evolution":

  • #0 poll
    from /lib64/libc.so.6
  • #1 g_main_context_poll
    at gmain.c line 4007
  • #2 g_main_context_iterate
    at gmain.c line 3708
  • #3 g_main_loop_run
    at gmain.c line 3907
  • #4 gtk_main
    from /lib64/libgtk-3.so.0
  • #5 main
  • #0 poll
    from /lib64/libc.so.6
  • #1 g_main_context_poll
    at gmain.c line 4007
  • #2 g_main_context_iterate
    at gmain.c line 3708
  • #3 g_main_context_iteration
    at gmain.c line 3774
  • #4 g_application_run
    at gapplication.c line 1635
  • #5 main
  • #0 poll
    from /lib64/libc.so.6
  • #1 g_main_context_poll
    at gmain.c line 4007
  • #2 g_main_context_iterate
    at gmain.c line 3708
  • #3 g_main_loop_run
    at gmain.c line 3907
  • #4 dbus_server_run_server
    from /lib64/libebackend-1.2.so.7
  • #5 ffi_call_unix64
    from /lib64/libffi.so.6
  • #6 ffi_call
    from /lib64/libffi.so.6
  • #7 g_cclosure_marshal_generic_va
    at gclosure.c line 1550
  • #8 _g_closure_invoke_va
    at gclosure.c line 840
  • #9 g_signal_emit_valist
    at gsignal.c line 3238
  • #10 g_signal_emit
    at gsignal.c line 3386
  • #11 e_dbus_server_run
    from /lib64/libebackend-1.2.so.7
  • #12 main
  • #0 poll
    from /lib64/libc.so.6
  • #1 g_main_context_poll
    at gmain.c line 4007
  • #2 g_main_context_iterate
    at gmain.c line 3708
  • #3 g_main_loop_run
    at gmain.c line 3907
  • #4 dbus_server_run_server
    from /lib64/libebackend-1.2.so.7
  • #5 ffi_call_unix64
    from /lib64/libffi.so.6
  • #6 ffi_call
    from /lib64/libffi.so.6
  • #7 g_cclosure_marshal_generic_va
    at gclosure.c line 1550
  • #8 _g_closure_invoke_va
    at gclosure.c line 840
  • #9 g_signal_emit_valist
    at gsignal.c line 3238
  • #10 g_signal_emit
    at gsignal.c line 3386
  • #11 e_dbus_server_run
    from /lib64/libebackend-1.2.so.7
  • #12 main
  • #0 poll
    from /lib64/libc.so.6
  • #1 g_main_context_poll
    at gmain.c line 4007
  • #2 g_main_context_iterate
    at gmain.c line 3708
  • #3 g_main_loop_run
    at gmain.c line 3907
  • #4 dbus_server_run_server
    from /lib64/libebackend-1.2.so.7
  • #5 ffi_call_unix64
    from /lib64/libffi.so.6
  • #6 ffi_call
    from /lib64/libffi.so.6
  • #7 g_cclosure_marshal_generic_va
    at gclosure.c line 1550
  • #8 _g_closure_invoke_va
    at gclosure.c line 840
  • #9 g_signal_emit_valist
    at gsignal.c line 3238
  • #10 g_signal_emit
    at gsignal.c line 3386
  • #11 e_dbus_server_run
    from /lib64/libebackend-1.2.so.7
  • #12 main


When attaching strace to the "evolution" process, I get the following lines seemingly repeatedly:

poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}, {fd=12, events=POLLIN}], 4, 203) = 1 ([{fd=6, revents=POLLIN}])
recvfrom(6, "\241 {Y\22\0\340\1}\1\0\0,\275\2\0\0\0\0\0\320!\356\234\6\0\0\0\0\0\0\0", 4096, 0, NULL, NULL) = 32
recvfrom(6, 0x24dc164, 4096, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(6, 0x24dc164, 4096, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(6, 0x24dc164, 4096, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}, {fd=12, events=POLLIN}], 4, 0) = 0 (Timeout)
poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\206\3\4\0\25\0\340\1\0\0\0\0-\275\2\0005\30\4\0\344\231\372\1\22\0\340\1\t\6\36\0"..., 16376}, {NULL, 0}, {"", 0}], 3) = 16376
recvfrom(6, 0x24dc164, 4096, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\212\nV\0\3\0\340\1\r\232\372\1\345\231\372\1$\0\0\0r\1\22\0\0\232\22\0\0\253\22\0"..., 16368}, {NULL, 0}, {"", 0}], 3) = 16368
recvfrom(6, 0x24dc164, 4096, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)


file descriptor 6 corresponds to a socket (lsof output):

evolution 2520 mildred    6u     unix 0xffff8803d56e7a80      0t0  1580371 socket
Comment 1 Mildred 2014-02-04 08:45:18 UTC
I posted the stack traces of all the evolution processes, but they get all collapsed in the same section. The stack traes are from the following processes in that order:

- evolution
- evolution-alarm-notify
- evolution-addressbook-factory
- evolution-calendar-factory
- evolution-source-registry
Comment 2 Mildred 2014-02-04 08:45:49 UTC
Created attachment 268043 [details]
screenshoot describing the problem
Comment 3 Mildred 2014-02-04 09:08:36 UTC
As I said on bug #723596 (which seems related) the problem was caused because:

- yesterday, the computer was put to sleep while still connected to the wired network
- this morning, I moved the computer to another network, plugged in the wired connection, and resumed the computer from sleep.

Applications did not notice a disconnect, and thus might think they are connected to the same network. However, this is not the case as the IP address changed. This causes a deadlock in both empathy and evolution.
Comment 4 Mildred 2014-02-04 09:13:01 UTC
Note, closing all processes called evolution or evolution-* and restarting them don't solve the problem. evolution is still stuck on restart.
Comment 5 Milan Crha 2014-02-04 18:24:54 UTC
Thanks for a bug report. I believe this is fixed by a change in bug #702709, thus please retest when 3.10.4 is out (some time next week, then a delay till your distribution picks the release and updates packages for you). Please, provide a feedback with the result on 3.10.4, as this might be eventually marked as a duplicate of the above bug report. Thanks in advance.
Comment 6 Mildred 2014-03-26 08:36:29 UTC
You are right, I no longer have this issue with evolution 3.10.4. Some other parts of the system might have changed as well. I noticed that NorworkManager puts the network offline for a brief moment when awakening from sleep.

Closing the bug.

*** This bug has been marked as a duplicate of bug 702709 ***