Hide Forgot
Created attachment 574778 [details] backtrace Description of problem: Evolution not closed after network failure
I can confirm, there is something wrong with evolution-networkmanager. Evolution is also not reconnecting to imap after suspend or other wireless lan loss. Because the title is imprecise I changed it.
Thanks for a bug report. I'm afraid that Mikhail's issue is ot that much related to evolution-NetworkManager, it's rather about evolution-ews, not closing itself after connection lost. The suspend is also poorly implemented in the camel providers and calendar/book backends in evolution, which is a semi-known issue. There is an advice to stop evolution before you suspend your machine. From the backtrace: I would expect seeing there the EWS account being stuck on a connection, but it isn't. Thread 4 is freeing the store, waiting for ews' soup thread to finish, but it doesn't need to do that for some reason. There is also Thread 3, which would like to update folder list, but it's waiting on the lock to be released by Thread 4. I found basically the same bug report upstream [1] (there is surely for suspend too, how about network manager I'm not sure), thus I'm moving this there. Please see [1] for any further updates. [1] https://bugzilla.gnome.org/show_bug.cgi?id=663383
*** Bug 835593 has been marked as a duplicate of this bug. ***
I made a test build [1] with upstream patches included. I'll appreciate if you could give it a try. Thanks in advance. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4218557
Created attachment 596396 [details] backtrace for evolution
Created attachment 596397 [details] backtrace for evolution 2
Today evolution with updated packages stuck twice on exit. I attached backtraces here.
This occurs after massive message deletion
Today stuck again. I don't know what is happens.... Also I attach new backtraces...
Created attachment 596989 [details] yet another backtrace for evolution (evolution stuck on recieve message)
Created attachment 596990 [details] yet another backtrace for evolution (evolution stuck on exit)
$ rpm -qa | grep evolution | sort evolution-3.4.3-2.fc17.i686 evolution-data-server-3.4.3-1.fc17.i686 evolution-data-server-debuginfo-3.4.3-1.fc17.i686 evolution-debuginfo-3.4.3-2.fc17.i686 evolution-ews-3.4.3-1.3.fc17.i686 evolution-ews-debuginfo-3.4.3-1.3.fc17.i686 evolution-exchange-3.4.3-1.fc17.i686 evolution-exchange-debuginfo-3.4.3-1.fc17.i686 evolution-mapi-3.4.3-5.fc17.i686 evolution-mapi-debuginfo-3.4.3-5.fc17.i686 evolution-NetworkManager-3.4.3-2.fc17.i686
*** Bug 837821 has been marked as a duplicate of this bug. ***
down/up em3 and we again hangs....
Created attachment 597015 [details] stuck again.... backtrace....
Created attachment 597017 [details] proof screenshot
I think it's waiting for a timeout on the connection, and after that it'll report failure to UI. I do not know what the default timeout is, but when I was testing my changes in the upstream bug then I made it smaller, to 10 seconds. Could you wait few minutes (I guess for 5 minutes max) to see whether this is really waiting for a connection timeout, please? If you run evolution from a terminal, then you might see changes there, like the information: > Unable to fetch the folder hierarchy: server.com: code where code is an error number, in your case usually 288, which is: EWS_CONNECTION_ERROR_NORESPONSE. You can see even more verbosity on the client-server communication if you run evolution with EWS_DEBUG=2 variable being set, though I'm not sure whether it'll be anyhow useful. Interesting is that the last backtrace (comment #15) is basically empty, each thread is in idle, while the other backtraces are showing activities in multiple threads, all waiting for a server response.
please check your mail. I send to you some info.
Got it, thanks. I see there that "WARNING **: No response: Cannot resolve hostname (xxx)", interestingly following network requests are working correctly. I also noticed in the log following runtime warnings: GLib-GObject-WARNING **: instance with invalid (NULL) class pointer GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed which are there before the "No response" warning. I'm building [1] a test package which has set 10 seconds timeout on connection, maybe it'll help to narrow things down (and to not wait that long for timeout after your interface or connection is down). [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4226662
Created attachment 597064 [details] yet another backtrace for evolution
https://docs.google.com/open?id=0B0nwzlfiB4aQS0N3NE8zTzNYOGM Please check your mail
Interesting. I see from the log that the lower timeout set on the soup session is not suitable for you, the log shows quite many timeouts. I also see in your video that the Send/Receive dialog is stuck in cancelling, though the backtrace shows that there is no pending operation in ews, basically the same as evolution being idle.
The issue in Send/Receive is not caused by EWS, it is a bug in evolution itself. I committed a fix for 3.4.4+ (commit dcab280) and 3.5.4+ (commit 82e9800) for it, and I'm currently building a test package of evolution at [1]. Please downgrade your evolution-ews package, to the previous version, without shortened timeout and then install test evolution package. It should be better now. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4229524
Thanks, I started testing. Another would be to defeat network problems in empathy. Empathy developers someday come here? I have an very interesting video for them. https://docs.google.com/open?id=0B0nwzlfiB4aQLTFlWHp2WUFfZDQ
So Evolution also stop receive any message after I restore connection. Please see my video, and check email for logs. https://docs.google.com/open?id=0B0nwzlfiB4aQcjJwQkJSVG5keXM Sorry for long video , but I want demonstrate how long time evolution do nothing. And helps only restart program.
(In reply to comment #24) > Thanks, I started testing. Another would be to defeat network problems in > empathy. Empathy developers someday come here? I have an very interesting > video for them. https://docs.google.com/open?id=0B0nwzlfiB4aQLTFlWHp2WUFfZDQ I'm afraid not. File a separate bug against emapthy, either here, or preferably at upstream: https://bugzilla.gnome.org/enter_bug.cgi?product=empathy
(In reply to comment #25) > So Evolution also stop receive any message after I restore connection. > Please see my video, and check email for logs. > > https://docs.google.com/open?id=0B0nwzlfiB4aQcjJwQkJSVG5keXM > > Sorry for long video , but I want demonstrate how long time evolution do > nothing. And helps only restart program. OK, it's either stuck or I missed one more place in evolution to report "done" state. The EWS logs are particularly useless, they do not bring anything interesting. I would prefer to see backtrace of evolution of this "Updating, but doing nothing" state. This is interesting, looking around the libsoup code I realized that its default timeout is 0, which means no timeout, the request will never stop on its own. Let's set timeouts to some sane value, say 2 minutes.
Here [1] is a test build which presets default connection timeout to 2 minutes. You can tweak the timeout by setting environment variable EWS_CONN_TIMEOUT to seconds you'd like to have timeout set for. The value is plain number and if it is not set properly, like it's a tring, zero or a negative value, then the 2 minutes timeout is used. I committed this change as commit 2d693ca to gnome-3-4 for 3.4.4+. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4232982
Created attachment 597521 [details] backtrace for evolution
Build from [Comment 28] not help to solve above problem. I add backtrace for this case.
Created attachment 597524 [details] backtrace for evolution
Created attachment 597525 [details] backtrace for evolution
And now all was hanging the whole UI. https://docs.google.com/open?id=0B0nwzlfiB4aQUElsRkhuSVRwQkU
Created attachment 597596 [details] backtrace for last case
*** Bug 839180 has been marked as a duplicate of this bug. ***
The three backtraces starting at comment #29 are basically the same, one thread is waiting for finish of e_ews_connection_sync_folder_items() call. Backtrace from comment #34 is similar, except there are 3 such threads. I see on one that it is called with NULL 'cancellable', which means it cannot be cancelled. Though it doesn't explain the UI freeze, because the main thread, which is responsible for UI, is not blocked in that backtrace. Ah, I see in the video, the UI is disabled, with grayed widgets. It's on purpose. Once you click to quit evolution it disables all its windows and then starts quitting. Such quitting is about synchronizing last changes into the server and evolution will not quit until there is no left pending operation. It had two pending operations in the status bar. There is also shown in the video that the UI is not frozen, because you resized the window and it properly updated inner widgets, thus it's just waiting for a response. I'm currently out of idea what could happen to the response, either it's completely lost or there's a bug in ews code that doesn't call operation callback for this request for some reason. I only know that I'm not able to reproduce this on my machine that easily as you, unfortunately.
Created attachment 597995 [details] backtrace for evolution
Still the same pattern, this time three threads in e_ews_connection_update_items(). I cannot tell from it whether the right connection is used in the waiting thread or not, due to current code changes. I created yet another test build which will show in the backtrace whether the same connection is used. You can download it from: http://koji.fedoraproject.org/koji/taskinfo?taskID=4244435
Created attachment 598564 [details] backtrace for evolution
$ rpm -qa | grep evolution | sort evolution-3.4.3-2.1.fc17.i686 evolution-data-server-3.4.3-1.fc17.i686 evolution-data-server-debuginfo-3.4.3-1.fc17.i686 evolution-debuginfo-3.4.3-2.1.fc17.i686 evolution-ews-3.4.3-1.6.fc17.i686 evolution-ews-debuginfo-3.4.3-1.6.fc17.i686 evolution-exchange-3.4.3-1.fc17.i686 evolution-exchange-debuginfo-3.4.3-1.fc17.i686 evolution-mapi-3.4.3-5.fc17.i686 evolution-mapi-debuginfo-3.4.3-5.fc17.i686 evolution-NetworkManager-3.4.3-2.1.fc17.i686
Created attachment 598594 [details] backtrace for evolution
Created attachment 598596 [details] backtrace for evolution
Created attachment 598633 [details] backtrace for evolution
Thanks for your testing and patience. I think I found finally the issue here. When I was looking into upstream bug for bug #807908, I realized that soup_session calls should be only done in soup_thread and if it's not, then in certain circumstances it can lead to such strange behaviour (see the upstream bug for more information). It should work fine, with this evolution-ews scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4246707
Great job, but evolution continue crashed https://bugzilla.redhat.com/show_bug.cgi?id=809866
Ops stuck with evolution-ews-3.4.3-1.9 version :(
Created attachment 599140 [details] backtrace for evolution (evolution-ews-3.4.3-1.9) stuck again
Created attachment 599192 [details] backtrace
Created attachment 599228 [details] backtrace evolution
Created attachment 599339 [details] yet another backtrace for evolution
Thanks for the update. I checked the changes and 1.9 didn't touch this part of the code, it did 1.8. Might be just matte of luck you didn't have 1.8 made stuck evolution. From the bakctraces, all but the one from comment #49 are waiting for a response from the server, but there is missing ews_soup_thread, which means it was quit meanwhile, probably for server failure. The one in comment #49 does have that thread, for the connection it uses in one thread, thus that one may recover after some time, or it just didn't get to the state as the other 4 backtraces.
Created attachment 600002 [details] proposed ews patch I think this should help, but as I cannot reproduce, and I'm not completely sure, then I would like to ask you for testing it before I'll commit to upstream sources. I'm currently building the 1.10 version [1] with this patch included. Please run evolution from console, just in case there will be anything interesting when/if you manage to reproduce this issue again. I do not want any special arguments or environment variables being set, just run it like this: $ evolution and attach here its output together with a backtrace. Thanks in advance. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=4325399
I do not see any backtraces in your bug reports which would suggest the patch from comment #52 is causing any issue. I'll wait over the weekend and if there will not raise anything, then I'll commit it to sources in the middle of the next week (I do not want to forget about it).
I committed the patch as commit b2b44d4 for master (3.5.5+) and as commit cd21324 for gnome-3-4 (3.4.4+) of evolution-ews.
*** Bug 841729 has been marked as a duplicate of this bug. ***
Today evolution stuck on exit again... $ rpm -qa | grep evolution | sort evolution-3.4.3-2.1.fc17.i686 evolution-data-server-3.4.3-1.3.fc17.i686 evolution-data-server-debuginfo-3.4.3-1.3.fc17.i686 evolution-debuginfo-3.4.3-2.1.fc17.i686 evolution-ews-3.4.3-1.15.fc17.i686 evolution-ews-debuginfo-3.4.3-1.15.fc17.i686 evolution-mapi-debuginfo-3.4.2-1.fc17.i686 evolution-NetworkManager-3.4.3-2.1.fc17.i686
Created attachment 602848 [details] backtrace evolution 2012-08-07
Created attachment 602849 [details] backtrace evolution 2012-08-07.1
Thanks for the update. The backtraces look fine, they have one EWS thread, which is idle - waiting for orders, and two other threads, waiting for an operation to be finished. It's hard to guess from the backtrace whether the requests are just waiting for a reply in some callback which is pushed somewhere, or what happened here. Do you have any idea what could happened before you closed evolution? In other words, what was the reason for closing evolution, was it a network disconnect? I agree that it's harder to spot the issue, at least for me, because we (with your help) addressed most of the issues with unreliable connection, thus I guess you are facing here some left corner-case, which requires pretty strict steps for a reproducer. I do not see anything obvious from code reading, unfortunately.
I am try to use Evolution with slow connection (64kbps)