Bug 812511
Summary: | Evolution 3.4 often hangs and refuses to work, cancel or even exit | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Pavel Šimerda (pavlix) <psimerda> | ||||
Component: | evolution | Assignee: | Matthew Barnes <mbarnes> | ||||
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 17 | CC: | lucilanga, mbarnes, mcrha, sanjay.ankur | ||||
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-04-17 06:26:09 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: |
|
Description
Pavel Šimerda (pavlix)
2012-04-14 08:40:01 UTC
Thanks for a bug report. I do not think this belongs to Fedora, there is nothing Fedora specific about it, and there are not used any extra patches which would influence this behaviour, thus this might come to Gnome's bugzilla. Nonetheless, let's try to gather more information first. Could you get a backtrace of hang Evolution, please? There should be shown what it tries to do - it is probably waiting for a response from the server. There were some changes in 3.3.x development cycle to be more cancellable responsive even in such situations, but either it doesn't work fully or this is about something else. You can get the backtrace with a command like this: $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt where PID is a process ID of running evolution (ps ax | grep evolution). Please make sure you'll have installed debuginfo packages for evolution, evolution-data-server and gtkhtml3, all of the same version as their binary counterparts. If you have installed other evolution packages, then install debuginfo for them as well. Before uploading bt.txt file, please make sure you'll not expose any private information, like you password or server name (I usually search for a "pass" word in it). Thanks, I never know which projects are better reported here or upstream. "Could you get a backtrace of hang Evolution, please? There should be shown what it tries to do - it is probably waiting for a response from the server." This is possible. It happened more often when one of the servers had problems itself. "Could you get a backtrace of hang Evolution, please?" Pity I could only read this after it hanged. Ok, next time. "Before uploading bt.txt file, please make sure you'll not expose any private information" Thanks. Created attachment 577685 [details]
backtrace
I found a way to reproduce this bug at will:
1) Run evolution and test that it works normally
2) Kill the network (I'm using RFKILL switch)
3) Click "Send / Recieve" when network is down
The funny thing is, that in this situation, no other programs hang, not even the basic utilities: [pavlix@dragon ~]$ ping example.com ping: unknown host example.com [pavlix@dragon ~]$ ping 1.2.3.4 connect: Network is unreachable [pavlix@dragon ~]$ nc -v 1.2.3.4 80 nc: connect to 1.2.3.4 port 80 (tcp) failed: Network is unreachable (In reply to comment #2) > Thanks, I never know which projects are better reported here or upstream. That's OK, I just wanted to mention it. One cannot know all packages, and I didn't mean it as any kind of offence. (In reply to comment #3) > I found a way to reproduce this bug at will: > 1) Run evolution and test that it works normally > 2) Kill the network (I'm using RFKILL switch) > 3) Click "Send / Recieve" when network is down Thanks, the imapx providers (I suppose you have two IMAP+ accounts configured) are waiting till their parser threads are finished, while these threads are trying to read from the conneciton. The thing is that the provider keeps the connection opened, and keeps waiting on a response on the connection which worked just few seconds ago (that's the difference from the basic utilities, whcih are creating new connections, while evolution keeps using the old one). Even this state should be better cancellable, and I thought that 3.4.0 will have it fixed. I found a similar upstream bug report [1], thus I would use it for any further investigation. I added there link to this bug report and your backtrace too. Please CC there if possible, in case an upstream developer will have further questions. [1] https://bugzilla.gnome.org/show_bug.cgi?id=667875 > I didn't mean it as any kind of offence.
None taken :).
Hello, I use POP with gmail and see this behaviour too. My network hangs up often and if evolution is in the middle of an update, "cancel" just changes the status to "cancelling" and it sits there. I eventually have to use xkill to kill it and restart evolution. CC ing myself to both this and upstream bugs. Thanks, Ankur |