GNOME Bugzilla – Bug 733081
[IMAPx] Job stuck after send when saving to IMAP server
Last modified: 2014-08-12 16:49:28 UTC
Created attachment 280537 [details] gdb 't a a bt' output for an affected Evo process Filing a new report for the follow-on problem I discovered from https://bugzilla.gnome.org/show_bug.cgi?id=732366 . The scratch build of e-d-s with the fix for that bug - http://koji.fedoraproject.org/koji/taskinfo?taskID=7117386 - does indeed fix it, but seems to cause a new bug. I have Evo configured such that when I send a mail, it stores the 'sent' copy not in the "on this computer" local account, but in the Sent folder of the IMAP server (that seems to be relevant here). With the e-d-s patched for #732366, quite often after I send an email, Evo gets stuck. I see the "sending message..." blue status bar appear and, shortly after, it briefly shows "Sending message (100% complete)". Usually at that point the window for the just-sent message would disappear and all would be well. However, when this bug hits, the status bar goes back to just "Sending message" and the window sticks like that, apparently forever. If I switch to the main Evo window I see other operations to the IMAP server piling up in the lower status area (folder refreshes), and I cannot open any mails that have not already been downloaded and cached - basically, any further communication with the server is blocked. The only escape is a killev. I attached gdb to the running Evo while it was stuck in this state, much as requested in https://bugzilla.gnome.org/show_bug.cgi?id=732366 . I'll attach the 't a a bt' output; I don't know which frame to look at in this case. Please advise! Thanks.
Note that the sent message *does* get successfully stored on the IMAP server.
Gah, and I forgot to note - the message send operation does actually work. The mail does get sent out, and (as per c#1) does get stored in the IMAP server's Sent folder; it's after both those things happen that Evo gets stuck, apparently.
Created attachment 280635 [details] [review] proposed eds patch for evolution-data-server; I think there left an incorrect IDLE state stored on the object, which then led to an "out of order" DONE command being issued on the connection, just in time of the message APPEND command, which confused the server enough to stop send of the APPEND command completion confirmation, for which the IMAPx is waiting. It may eventually fix also Yaneti's issue.
Running with attachment 280635 [details] [review] for the last 10-15 minutes and I've been able to reliably send myself 2-3 messages that get appended to a Sent folder on the same server. I'll have to run this longer to see if it gets stuck somewhere.
Created attachment 280686 [details] [review] proposed eds patch ][ for evolution-data-server; Hrm, I noticed some critical warnings on the console caused by the previous patch. I thought of this and I believe the main issue was the way I tried to solve bug #730788, which led to bug #732366 and finally here. I simply chose an incorrect approach. The right way to fix all of these issues should be this new patch. I was using it for some time and it seems correct. Please revert the previous patch from here and apply this one (it's cleanly applicable on git master) and let me know. Thanks in advance.
Created attachment 280716 [details] [review] proposed eds patch ]I[ for evolution-data-server; A mix of the previous patches. I'm still not able to reproduce this reliably, otherwise I would provide more consistent fix. I'm sorry for that.
It fixes the issue in my case. The bug is reproducable here, the message window hangs everytime I send a message and evolution has to be killed.
Thanks for the testing. I've got a confirmation from Yanko too (on IRC), thus I'm moving the patch to sources. I will also create a ...-2 update for Fedora, for those interested. Created commit e60f804 in eds master (3.13.4+) [1] Created commit b8456c7 in eds evolution-data-server-3-12 (3.12.5+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=e60f804
sorry I never got around to testing the patches, been a bit crazy here the last few days! I'm installing the new F21 package now, will let you know if I see further problems. thanks!
That's OK. Yaneti opened bug 733314 where we do some follow-up debugging, because the issue is still not fixed. Once we debug it there, I will mark it as a duplicate of this bug report and will update this bug report with the follow-up change. It might be tomorrow, with a bit of luck (we had 3 iterations already today) :)
well, I installed the -2 build for F21 and put my Evo back to the problematic settings (1 minute checks, IDLE enabled) and haven't seen it get stuck in either way since, but maybe I've just been lucky.
Right, you might be just lucky, the same as I am. I found a flaw in the code while investigating the issue with Yaneti, which we are fixing meanwhile.
*** Bug 733314 has been marked as a duplicate of this bug. ***
The follow up change landed as: Created commit 738e1f0 in eds master (3.13.4+) [1] Created commit 80c281d in eds evolution-data-server-3-12 (3.12.5+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=738e1f0
*** Bug 733410 has been marked as a duplicate of this bug. ***
In order to not only complain and report new bugs: :-) It seems that these patches have fixed that particular problem for me.
I confirm, that the patchs seems to have fixed the problem for me.
*** Bug 733868 has been marked as a duplicate of this bug. ***