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: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: 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 Flags
backtrace none

Description Pavel Šimerda (pavlix) 2012-04-14 08:40:01 UTC
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-3.4.0.1-1.fc17.x86_64 and many versions before.

Reproducability:

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.
  
Actual results:

Most of the actions sometimes fail but Evo won't ever recover from them and won't cancel them at user request.

Expected results:

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.

Additional info:

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.

Comment 1 Milan Crha 2012-04-16 06:58:54 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).

Comment 2 Pavel Šimerda (pavlix) 2012-04-16 11:24:01 UTC
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.

Comment 3 Pavel Šimerda (pavlix) 2012-04-16 11:33:45 UTC
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

Comment 4 Pavel Šimerda (pavlix) 2012-04-16 11:37:39 UTC
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

Comment 5 Milan Crha 2012-04-17 06:26:09 UTC
(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

Comment 6 Pavel Šimerda (pavlix) 2012-05-03 07:40:08 UTC
> I didn't mean it as any kind of offence.

None taken :).

Comment 7 Ankur Sinha (FranciscoD) 2012-06-18 14:09:29 UTC
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