Red Hat Bugzilla – Bug 812511
Evolution 3.4 often hangs and refuses to work, cancel or even exit
Last modified: 2012-06-18 10:09:29 EDT
Evolution 3.4 often keeps trying to connect somewhere, be it IMAP or SMTP, and never succedes until killing it with SIGKILL and trying with a new instance. Its GUI often still responds but there are not many things you can do.
Especially the cancel button during any send/recieve actions only grays out after clicking and nothing happens until kill -9.
It's evolution-22.214.171.124-1.fc17.x86_64 and many versions before.
random, but very often, let's say many times an hour if you work with the mail client actively
Steps to Reproduce:
1. Use Evolution for IMAP sending and recieving
It may be tricky to reproduce because it may be depending on some circumstances. I can try to provide more info as needed.
Most of the actions sometimes fail but Evo won't ever recover from them and won't cancel them at user request.
All actions should either succeed or fail in reasonable time.
Cancel button should cancel things, this is probably it's purpose! Same for Cancel all.
It may be that this bug or a series of bugs in Evolution are triggered by something you don't experience. Please test at least the „cancel“ case,
test also killing NM connections during Evo run, and finally, test also totally broken cases like a SMTP connection to a firewalled host, to a STARTTLS host, cleartext, and so on.
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
Created attachment 577685 [details]
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 126.96.36.199
connect: Network is unreachable
[pavlix@dragon ~]$ nc -v 188.8.131.52 80
nc: connect to 184.108.40.206 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 , 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.
> I didn't mean it as any kind of offence.
None taken :).
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.