Bug 835593
Summary: | Evolution again stuck after network problem | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mikhail <mikhail.v.gavrilov> | ||||||||||||||||
Component: | evolution | Assignee: | Matthew Barnes <mbarnes> | ||||||||||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||
Priority: | unspecified | ||||||||||||||||||
Version: | 17 | CC: | lucilanga, mbarnes, mcrha | ||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||
Target Release: | --- | ||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||
Whiteboard: | |||||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||
Last Closed: | 2012-07-04 16:07: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: | |||||||||||||||||||
Attachments: |
|
Created attachment 594497 [details]
screenshot
Thanks for a bug report. The status bar corresponds to the backtrace, and the backtrace doesn't do anything else, it's "retrieving" a message in one thread and is "checking" for new messages in another thread. The parser thread is idle, where actual communication with the server should be happening. Are you able to reproduce this on will, please? What are you doing to reproduce it? If you try to reproduce with evolution being run from a terminal, is there anything printed when you get to this kind of state? > Are you able to reproduce this on will, please? Yes. > What are you doing to reproduce it? Down my main Ethernet interface for a long time (~1 hour) and use internet through Android 2.2 mobile (Ethernet over USB) $ ifconfig em3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.10.8.58 netmask 255.255.255.0 broadcast 10.10.8.255 inet6 fe80::21c:c0ff:fe4b:df83 prefixlen 64 scopeid 0x20<link> ether 00:1c:c0:4b:df:83 txqueuelen 1000 (Ethernet) RX packets 863604 bytes 487440678 (464.8 MiB) RX errors 0 dropped 3983 overruns 0 frame 0 TX packets 887174 bytes 395875156 (377.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 20 memory 0x90300000-90320000 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Local Loopback) RX packets 17676 bytes 25464521 (24.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 17676 bytes 25464521 (24.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::487d:e8ff:fec8:faae prefixlen 64 scopeid 0x20<link> ether 4a:7d:e8:c8:fa:ae txqueuelen 1000 (Ethernet) RX packets 125135 bytes 150075380 (143.1 MiB) RX errors 3 dropped 0 overruns 0 frame 3 TX packets 87501 bytes 13598264 (12.9 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Means I down em3 and still use internet (my mail server is unavailable) When I reproduced the situation, empathy also stop work after em3 is up again. and empathy has not begins work even after a restart! it seems the problem is buried somewhere in the system :( > If you try to reproduce with evolution being run from a terminal, > is there anything printed when you get to this kind of state? no Created attachment 594931 [details]
empathy debug log
Created attachment 594932 [details]
yet another backtrace for evolution
Other network software Google Chrome and gvfs after it happened continue to operate normally without having to restart. Created attachment 594984 [details]
yet another backtrace for evolution 2
Thanks for the update. I do not know the empathy at all. From its log I see interesting lines: > tp-glib/connection-DEBUG: 28.06.2012 11:42:36.422811: > tp_connection_continue_introspection: CORE ready, but not CONNECTED and then > tp-glib/connection-DEBUG: 28.06.2012 11:47:06.630127: > _tp_connection_got_properties: Calling GetStatus > tp-glib/connection-DEBUG: 28.06.2012 11:47:31.631125: > tp_connection_got_status_cb: 0xa9b3e68 > tp-glib/connection-DEBUG: 28.06.2012 11:47:31.631143: > tp_connection_got_status_cb: 0xa9b3e68: GetStatus() failed with dbus-glib- > error-quark 4 "Did not receive a reply. Possible causes include: the remote > application did not send a reply, the message bus security policy blocked > the reply, the reply timeout expired, or the network connection was broken." The log contains many timeout notices, thus I guess some DBus service used by empathy got unloaded or is stuck with something. This might be good to consult with empathy developers. The evolution backtraces are basically the same as the first one, except the last backtrace, which is also stuck (waiting) in message create operation. I'm wondering, did this happen after some update? I searched for libsoup, glib2 and glib-networking updates and all of these happened month before you filled this bug report, thus these might not be related? You can see what was updated and when in /var/log/yum.log file. I can not say exactly because that is not so long ago, using evolution-ews Created attachment 596147 [details]
yet another backtrace for evolution, again stuck when I try exit
Created attachment 596148 [details]
screenshot which demonstrate it
I think I found an issue here, let's move to the upstream bug associated on your previous bug #809364. I'll provide a test package with relevant patches on bug #809364 too. *** This bug has been marked as a duplicate of bug 809364 *** |
Created attachment 594496 [details] backtrace evolution Description of problem: Evolution again stuck after network problem