GNOME Bugzilla – Bug 742167
Stuck when going online
Last modified: 2017-10-26 11:46:53 UTC
Created attachment 293532 [details] bt-evolution.txt It doesn't occur always and I don't know how to exactly reproduce, but it occurs really often: When I close evolution after some days of usage, it takes forever to close and I always end up needing to run "evolution --force-shutdown" to finish it at the end. Just now the bottom box shows that it's trying to reconnect to an imap gmail account forever (but I am unsure that every time I see this it's due to the same process) I have got the attached trace running: gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt-evolution.txt Thanks for your help
Thanks for a bug report. The below threads seems to be the cause. I would guess from it that you've an intermittent disconnect from your network and then a reconnection, which lead to this "set online" state on a mail account (CamelStore), which wanted to connect the store, but that didn't finish properly. I miss a corresponding thread for this 'connect' operation, which means either it finished, but didn't let the caller know, or it is piled somewhere in a queue. I do not see from the backtrace what is the case.
+ Trace 234525
Thread 6 (Thread 0x7f57b6ffd700 (LWP 6154))
It's true that is likely to be caused by reconnections because the network I need to connect during this last days is really unstable :S, then, maybe the router got restarted during the quitting of evolution and it caused the issue :/
Bugzilla tags the trace as similar to bug 738421, but in this case I am sure it wasn't sending mails (probably was trying to fetch them instead)
I just wanted to add my "me too" here. For me, evolution appears to hang each time after wake up from suspend and fails to go back online, with "evolution --force-shutdown" as the only remedy left. I'm on Arch Linux, so I'd have to rebuild everything with debugging symbols myself in order to get a backtrace, and I just don't feel like doing so right now...
Just in case, I do not see exact versions being mentioned, just the version field says 3.12.x. There had been done some fixes around online/offline state and network switching, some landed in time of 3.12.8, but even more, more or less related, changes landed up to the 3.12.10/3.12.11. These changes were done mostly in evolution-data-server, but some also in evolution itself. Do you both have any or higher of these versions, please?
*** Bug 747234 has been marked as a duplicate of this bug. ***
*** Bug 750423 has been marked as a duplicate of this bug. ***
(In reply to Milan Crha from comment #5) > Do you both have any or higher of these versions, please? This problem still happens in 3.16.2 and flaky wifi; see bug 750423.
*** Bug 752589 has been marked as a duplicate of this bug. ***
*** Bug 765916 has been marked as a duplicate of this bug. ***
I tried to reproduce this yesterday, but no luck, unfortunately. I guess my manual network connect/disconnect attempts did not qualify as the "flaky WiFi". It's hard to fix this without being able to reproduce it. I've a debugging patch which tried to print on console what happens when the mail accounts are connected and disconnected, thus if anyone is willing to give it a try, then I'll be happy to provide it, even as a test package (though only for Fedora). What my wild guess is: a) either the connect attempt had been cancelled, then the ongoing operation wasn't finished properly for some reason; b) or the delivery of the "finish" signal failed maybe due to it being pushed into an incorrect GMainContext, because the camel_service_connect_sync() creates its own main context, which can block deliveries to the parent/previous main context. This happened with the book and calendar clients in the past; c) or something completely different...
*** Bug 764044 has been marked as a duplicate of this bug. ***
I've got back to this, after seeing it here accidentally (open evolution and close it before all mail accounts are connected; it caused never-ending closing of evolution in some cases). (In reply to Milan Crha from comment #11) > a) either the connect attempt had been cancelled, then the ongoing operation > wasn't finished properly for some reason; The a) is correct. Even the operation had been cancelled, it was never properly finished, due to the connection_op_cancelled() unreffing the associated GTask, which didn't necessarily also finish it. I dropped this function completely from the code, because it cases trouble. It's up to the descendant of CamelService to stop the connect/disconnect operation as soon as possible after it's cancelled. The unref of GTask is also bad, as had been proved by the users. Created commit ab0a16e19 in eds master (3.27.2+) Created commit 44b9d8266 in eds gnome-3-26 (3.26.2+)