Bug 1440734
| Summary: | [IMAPx] Indefinite waiting for message download | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lubomir Rintel <lrintel> |
| Component: | evolution | Assignee: | Milan Crha <mcrha> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | desktop-qa-list, fidencio, jkoten, jurikolo, lkundrak, lrintel, lucilanga, mbarnes, mcrha, tpopela, vrutkovs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | evolution-3.24.3 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1111600 | Environment: | |
| Last Closed: | 2017-05-09 14:13:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Lubomir Rintel
2017-04-10 11:52:58 UTC
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. 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 |