GNOME Bugzilla – Bug 697710
Going offline doesn't disconnect remote stores
Last modified: 2013-09-21 13:34:51 UTC
When going to offline, by pressing the online/offline button on the left of the status bar, the remote stores are not disconnected. One can notice since a fix for bug #271262, the disconnected stores are insensitive in Send/Receive menu. My steps: a) evolution --offline b) check Send/Receive menu (or toolbar popup), remote stores are insensitive c) go Online (by clicking the online/offline button) d) when activities in status bar settle, you can see all Send/Receive connected stores enabled (sensitive) e) click Online/Offline button to go offline again f) answer "Do not synchronize" - I rarely let it synchronize g) when activities in status bar settle, check the Send/Receive menu, you'll see that for example IMAP stores are still sensitive, while store like POP3 is not. All remote stores should be insensitive, like in step b)
Created attachment 241148 [details] [review] evo patch for evolution; This is fixing that. The reason was that the EActivity in prepare-for-offline has set its CamelOperation before a call to mail_cancel_all(), thus even this new CamelOperation was cancelled, before it got used. Moving the cancellable setup below fixes the disconnect, but...
...but I've got a crash on an IMAPX store disconnect finish, thus the patch cannot be committed as such: > *** glibc detected *** evolution: double free or corruption (fasttop): > 0x0000000002f884f0 ***
+ Trace 231762
Thread 2 (Thread 0x7fd82dad9700 (LWP 10141))
I tried to revert change from bug #271262, and I get a similar crash, the only difference is that it crashes in the Thread 1, not in a dedicated thread like in the above bracktrace. The backtrace is also shorter.
I cannot reproduce the crash in 3.8.0 (I might be just lucky?), thus I'm moving this to 3.9.x.
mail_account_store_service_notify_cb() should schedule an idle callback instead of updating the tree model directly from the signal handler. That would fix the GTK+ calls from the wrong thread.
(In reply to comment #5) > mail_account_store_service_notify_cb() should schedule an idle callback instead > of updating the tree model directly from the signal handler. That would fix > the GTK+ calls from the wrong thread. Right. Weird is that I do not get the crash in 3.8. Nonetheless, I'm going to try the schedule thing.
Created attachment 241244 [details] [review] evo patch ][ for evolution; OK, this adds the schedule of the notify_cb on idle, which seems to do the trick. The only thing is that I god another crash in ews code, but it can be (also) related to bug #670939 which I had applied. An EWS provider crashed on finalize, when it tried to disconnect its service. I'll test more and update this bug with my findings.
Hrm, I cannot reproduce the EWS crash again, let's do this: Created commit 765a50d in evo master (3.9.1+)