Since recently, a bug that looks very reminiscent of bug #1111600 started to occur more frequently on my Fedora installation. I suspect the problem perhaps never really went away. Version-Release number of selected component (if applicable): evolution-3.22.6-2.fc25.x86_64 evolution-data-server-3.22.7-1.fc25.x86_64 +++ This bug was initially created as a clone of Bug #1111600 +++ Description of problem: With the 7.0 GA version of evolution, when clicking to a message there's a very high chance (around 50%) that it won't reload. The status bar indicates "Retrieving message" task being perpetually restarted. Version-Release number of selected component (if applicable): evolution-data-server-3.8.5-24.el7.x86_64 How reproducible: It happens to me very often after I just click the message title to load it. Additional info: When I comment out evolution-data-server-3.8.5-imapx-check-cancelled-jobs.patch the issue goes away.
Thanks for a bug report. Backtrace 10 to backtrace 20 show basically the same thing, one thread is in IDLE, another thread tries to download a message. Interestingly, the g_socket_receive_with_timeout() is called with timeout -1, but IMAPx does set timeout to 90 seconds here: https://git.gnome.org/browse/evolution-data-server/tree/camel/camel-network-service.c?h=gnome-3-22#n623 and here: https://git.gnome.org/browse/evolution-data-server/tree/camel/camel-network-service.c?h=gnome-3-22#n650 as its default timeout. IMAPx itself also plays with the timeout, but never sets it to -1. I do not think that GSSAPI login has anything to do with it, but maybe it does (I do not use it myself). Back to bactraces, there happened something in time of backtrace 21, the IDLE thread is gone, it seems to me that a periodic refresh time had been reached thus a refresh happened. There is still one thread waiting for a response from the server. There is still one thread down to backtrace 30, which is still trying to download message 199043, but that thread looks differently this time, it cancelled the previous connection and it's trying to gain a new connection, but waiting for GTask to gain a free thread (there are only up to 10 threads available for GTask-s and even it has some mechanism to allocated more threads that mechanism doesn't really work [1]). I suppose that if you cancel the stuck message download and then select a different message and back the previous then it'll work again, because all that seems to be cancellable. I do not see what happened to the connection in the background, unfortunately. It's unlikely that you had some intermittent connection issue, right? For such cases would that 90 seconds timeout work, though I do not see why it got lost somewhere, when it's clearly being set. The timeout is not a fix for the lost connection, but it would at least not wait forever.
Oops... [1] https://bugzilla.gnome.org/show_bug.cgi?id=774448
I pushed your change upstream (offered on IRC): Created commit_80c5a32 in evo master (3.25.2+) [1] Created commit_1b3d8b0 in evo gnome-3-24 (3.24.3+) [1] https://git.gnome.org/browse/evolution/commit/?id=80c5a32