Created attachment 941250 [details] Screenshot showing the text attachment and the Evolution email with error dialog Description of problem: After updating evolution a few weeks ago via "yum update", sending an email with a large (500K) pdf attachment stopped working. After clicking the Send button, the "Send x% complete" message appears, but never disappears. Only way out is to click Cancel. Receiving large email attachements works fine. Version-Release number of selected component (if applicable): x86_64 fedora 20 with "yum update" done through September 25, 2014. Evolution 3.10.4. It has been updated as part of the above :yum update" process. Last one was today, September 23, 2014. How reproducible: Always. My wife originally told me about this when she was not able to send a pdf attachment that she has been sending monthly (different file each month) for quite some time. Just started a few weeks ago. There was an update to evolution a few weeks ago. Note: I had my wife's cousin, who runs Debian + email Thunderbird, send me her attachment. Thunderbird had no problem sending the attachment. I narrowed down the attachment file size that fails to send by creating text files with specific sizes. All text files consisted of lines looking like 1234567890... repeated so that each line, including the newline character, was 100 bytes. The last line was appropriately truncated. Sending an email with an 814-byte attachment works fine. Sending an email with an 815-byte attachment fails. After clicking Send, a "100% complete" message appears at the top of the email. The clock/circular dots continues to spin. After 2-3 minutes, an error dialog box containing the message "Timeout while waiting for command" appears. Note: the error message my wife saw was "I/O operation timed out". Steps to Reproduce: 1. Create a text file containing exactly 815 bytes. 2. Create an email. Attach the file. 3. Click Send. Actual results: Email is not sent. See attached screenshot. It shows the 815-byte text file and the evolution error dialog with the email behind it. Expected results: Email successfully sent. Note: testing with an 814-byte attachment works as expected. Additional info: 1. The email addresses shown in the screenshot are real. Please do not share them with others. Thanks. 2. I did enter an item 2 days ago into fedoraforum under "using fedora" about this, hoping that someone there could help. None so far.
Thanks for a bug report. I didn't hear of anything similar before. I tried to reproduce this, but no luck, my message with 889bytes was properly sent, using up to date Fedora 20 with: evolution-3.10.4-4.fc20.x86_64 evolution-data-server-3.10.4-5.fc20.x86_64 Wouldn't it be possible that you save your sent messages into the IMAP folder, thus this timeout comes rather from the "save the sent message" than from the send itself? In any case, could you install debug-info packages for evolution-dat-aserver and evolution, then reproduce the issue, and while evolution is stuck catch a backtrace of it to see where exactly it is stuck, please? You can get the backtrace with this gdb command: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).
Sorry for the delay. I've been researching on how to install the debuginfo packages. (I'm new to this process.) Before I do, I have a couple of questions. 1. I found the two rpm packages at rpmfind, but am hesitant to install the rpm packages outside of yum. I then found the "debuginfo-install" command which appears to be what I want. In particular, I will install them using the command (as root) (no quotes) "debuginfo-install evolution evolution-data-server" Question 1: is this the correct procedure? 2. I notice in your reply that I should enter the gdb command after I've clicked send and evolution is stuck. Your sample invocation implies that I do this as a normal user, not as root. Question 2: is this correct? I apologize for the trivial questions. Just want to be sure I do what you want.
(In reply to John Ganci from comment #2) > Sorry for the delay. I've been researching on how to install the debuginfo > packages. (I'm new to this process.) Before I do, I have a couple of > questions. > 1. I found the two rpm packages at rpmfind, but am hesitant to install the > rpm packages outside of yum. I then found the "debuginfo-install" command > which appears to be what I want. In particular, I will install them using > the command > (as root) (no quotes) > "debuginfo-install evolution evolution-data-server" > Question 1: is this the correct procedure? Perfectly correct. I'm sorry I didn't give more hints on this. > 2. I notice in your reply that I should enter the gdb command after I've > clicked send and evolution is stuck. Your sample invocation implies that I > do this as a normal user, not as root. > Question 2: is this correct? This is also correct, run gdb as the same user which run evolution.
Created attachment 944686 [details] Output from gdb command run while evolution was hung. The bt.txt file is the one requested by the assignee. Contains the output of a gdb command run while evolution was hung.
I had my reply all typed in. Then I wanted to add the attachment. Did so at the top here. When I got back to here, my replay was gone. Grumble. I'll enter it again. I've done what you asked. bt.txt file already attached. 1. Ran the debuginfo-install command. Many more debuginfo files had to be installed. Did that. 2. Got "root partition low on space". Looks like I will have to delete the debuginfo packages when done here. 3. Logged out then back in. Started evolution. 4. Ran "ps -aux | grep evolution" (no quotes) to get the PID for evolution. Also verified it using top. 5. Copied your gdb command skeleton to a gedit session. Replaced the -pid=`pidof evolution` with -pid=`7095`. (Should've also removed ticks; see below.) 6. Copied the edited gdb command to terminal window. Preparing for step 8. 7. Created email with 815 byte attachment. Sent it. Evolution hung. 8. Pressed enter in the terminal window containing the gdb command. Got error due to tick marks. Canceled the hung evolution send, removed the tick marks from the gdb command, repeated step 7. When evolution hung, pressed Enter for the gdb command. Worked this time. 9. The gdb command ran for several seconds, then ended while evolution was still hung. Eventually evolution displayed error dialog with message "Timeout while waiting for command". 10. At this point canceled the stuck email. Sent the bt.txt attachment, then (re)typed this response. Two questions. Q1. Okay for me to delete the debuginfo packages? I'd like to get my root partition back to not being low on space (currently has ~850M; I assume 1G is the magic number for not being low on space). Q2, Do I delete them by issuing (as root) "yum remove evolution-debuginfo evolution-data-server-debuginfo <and the other debuginfo packages that were brought in>"?
Thanks for the update. Sure, you can remove all the debuginfo packages. I forgot it brings in many other files, you can install debuginfo for particular packages only with: $ yum install evolution-debuginfo --enablerepo=updates-debuginfo which repo to enable depends from which repo you've evolution installed (or any other package). To remove them you can use the classic 'yum remove' as you did before (or you can even try: $ yum remove `rpm -qa | grep debuginfo` Note this is how you copy&paste it into the terminal, there is no need to do anything else. Like the `pidof evolution`, the "pidof" is an executable. I looked into the backtrace and it shows that the SMTP provider is waiting for a response from the server. I would try other connection options, like TLS instead of SSL or vice versa, or choose different authentication type, or something like that.
I removed the debuginfo packages using your suggestion. Had to run one more for yum-plugin-auto-update-debug-info.noarch 0:1.1.31-23.fc20 due to the debug-info instead of debuginfo. Back to 3.1G free. Those packages consume almost 3G! Sorry about my misreading of the `pidof evolution`. It's been quite a while since I used the `command` technique. I did learn a new command - pidof. Are you suggesting that I might have a problem with my internet provider (Verizon)? Am I on the hook to do something? How do I show/change the connection options and/or authentication type?
(In reply to John Ganci from comment #7) > I removed the debuginfo packages using your suggestion. Had to run one more > for yum-plugin-auto-update-debug-info.noarch 0:1.1.31-23.fc20 due to the > debug-info instead of debuginfo. Back to 3.1G free. Those packages consume > almost 3G! I guess the yum's debuginfo downloaded brought in also debuginfo for webkitgtk3, which is not needed, but which takes most of the disk space from those almost 3GB. > Are you suggesting that I might have a problem with my internet provider > (Verizon)? I do not want to blame them, this is only what I see in the given backtrace (at comment #4), the SMTP part is waiting for a response from the server. > Am I on the hook to do something? How do I show/change the connection > options and/or authentication type? You can get to the options in Edit->Preferences->Mail Accounts-><the offending account>->Edit->Sending Email tab. You can see there both Security and Authentication options.
I apologize for the long delay in replying. My current email security settings are "No encryption" for Encryption method and "PLAIN" for Authentication Type. I've never knowingly changed these values. Since the ability to send emails having large attachments worked fine in the past, I don't see how the above settings could have an effect. However, if you insist, I will go through some of the (encryption method, authentication type) permutations to see if anything changes. Also note that in addition to being unable to send an email with a large attachment, I also cannot send an email whose text exceeds 815 bytes. This also worked in the past. Very frustrating, as you can imagine.
Yes, I understand it's frustrating. The thing is that I was not able to reproduce this with my server. I'm trying to figure out whether your server isn't unhappy with certain authentication methods or anything like (or other than) that (anything can be related), that it doesn't work for you, but it does for me. As I said in comment #8, the backtrace shows evolution waiting for a response from the server.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.