Description of problem: Fresh install, Evolution set up to receive mail from my gmail account via IMAP, see screenshots for details Version-Release number of selected component (if applicable): $ rpm -qa | grep evolution evolution-data-server-3.4.3-1.fc17.x86_64 evolution-help-3.4.3-1.fc17.noarch evolution-bogofilter-3.4.3-1.fc17.x86_64 evolution-3.4.3-1.fc17.x86_64 evolution-NetworkManager-3.4.3-1.fc17.x86_64 How reproducible: This is third profile, same result. Steps to Reproduce: 1. Create a fresh profile 2. Run evolution and add gmail account via IMAP Actual results: after a while, evolution will show many “downloading” messages, but does not really refresh the email. After a few attempts it may get to the point of fetching all headers, but needs to be killed frequently to be usable. Expected results: mail to be usable Additional info:
Created attachment 593957 [details] Evolution mail with... no email and many failed connections
Thanks for a bug report. Did you setup the IMAP account on your own or by Gnome Online Accounts? If by hand, what is your exact setting of the receiving part of the account, please? I would also try to run evolution from console, and see what it prints there, maybe there will be printed detailed error messages. It'd be usable to know where is evolution stuck, which can be read from a backtrace of running evolution. If you install debuginfo packages for evolution-data-server and evolution, of the same version as your binary packages are, and then run evolution to get into the "loading" state, then invoke this command: $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt where PID is process ID of running evolution (ps ax | grep evolution). The bt.txt file will probably contain private information, like your password to gmail account, thus please make sure it'll not exhibit any private information you do not want to share in public (search it for your email address, and then also for "pass" (quotes for clarity only) to check passwords).
Created attachment 594277 [details] "Reciving email" section of my account settings
Created attachment 594278 [details] "Reciving email" section of my account settings
Created attachment 594279 [details] "Reciving options" section of my account settings
(In reply to comment #2) > Thanks for a bug report. Did you setup the IMAP account on your own or by > Gnome Online Accounts? If by hand, what is your exact setting of the > receiving part of the account, please? I would also try to run evolution > from console, and see what it prints there, maybe there will be printed > detailed error messages. I've set up an account by hand. Funnilly enough, I have a laptop with Fedora 17 and Evolution is working just fine on it. Though the difference is, I've installed Fedora 17 beta on laptop, while on my desktop I've installed final Fedora 17. After a few attempts, I can see email being loaded, but it works for first 1-2 minutes, then it gets stuck and does not download messages, does not refresh, untill I kill it and start it again. If I do any change to settings, then it shows just empty screen. My Reciving Email and Options pages from config are attached to this bug report.
(In reply to comment #2) > I would also try to run evolution > from console, and see what it prints there, maybe there will be printed > detailed error messages. when I run evolution from the command line, the only errors I get are those: (evolution:4311): Gtk-WARNING **: Theme parsing error: <data>:1:0: Expected an identifier (evolution:4311): Gtk-CRITICAL **: gtk_css_section_get_file: assertion `section != NULL' failed (evolution:4311): Gtk-CRITICAL **: gtk_css_section_get_end_position: assertion `section != NULL' failed (evolution:4311): Gtk-CRITICAL **: gtk_css_section_get_end_line: assertion `section != NULL' failed and repeated all over again, then when I kill it: (evolution:4311): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: Operation was cancelled so nothing really useful
(In reply to comment #2) > It'd be usable to know where is evolution stuck, which can be read from a > backtrace of running evolution. If you install debuginfo packages for > evolution-data-server and evolution, of the same version as your binary > packages are, and then run evolution to get into the "loading" state, then > invoke this command: > $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt > where PID is process ID of running evolution (ps ax | grep evolution). > > The bt.txt file will probably contain private information, like your > password to gmail account, thus please make sure it'll not exhibit any > private information you do not want to share in public (search it for your > email address, and then also for "pass" (quotes for clarity only) to check > passwords). see attached bt.txt -- gdb runs for a couple of seconds and stops...
Created attachment 594281 [details] backtrace from Evolution
Thanks for the update. I see you are using IMAP+. I was told recently that there are certain issues with IMAP+ and its Quick Resync and Listen for server notifications options, thus I would try to disable these two options. I cannot find the exact bug link where I saw this currently, I'm sorry. Note such change requires restart of evolution to take into effect. From the backtrace I cannot read much, it's missing all the debug information. it seems like the IMAP+ account is waiting for a finish of update operation, under camel_folder_synchronize_message_sync (), in couple threads, but this request got lost somewhere or is stuck due to other pending update request. I use IMAP (not IMAP+) with Google account and it work fine for me.
(In reply to comment #10) > Thanks for the update. I see you are using IMAP+. I was told recently that > there are certain issues with IMAP+ and its Quick Resync and Listen for > server notifications options, thus I would try to disable these two options. > I cannot find the exact bug link where I saw this currently, I'm sorry. Note > such change requires restart of evolution to take into effect. > > From the backtrace I cannot read much, it's missing all the debug > information. it seems like the IMAP+ account is waiting for a finish of > update operation, under camel_folder_synchronize_message_sync (), in couple > threads, but this request got lost somewhere or is stuck due to other > pending update request. I use IMAP (not IMAP+) with Google account and it > work fine for me. Ok, I've unchecked those options, it didn't help. Then I've changed from IMAP+ to IMAP, it didn't help... so I removed the account, added it again as IMAP -- this time could see list of mail loading, but could not see any of them. But, after killing evolution and starting it again... suddenly, my all mail was there! :) Additional note: when evolution was opening a zillion connections to imap+ on gmail, if left in that state for 5 minutes or more, it was affecting my desktop's performance -- at first I thought it was just gnome-shell, but killing evolution immediately helped. Strange -- not sure why it would affect X server... though I am using nouveau drivers for my NVIDIA card, they're not perfect yet.
(In reply to comment #11) > Ok, I've unchecked those options, it didn't help. Then I've changed from > IMAP+ to IMAP, it didn't help... so I removed the account, added it again as > IMAP -- this time could see list of mail loading, but could not see any of > them. But, after killing evolution and starting it again... suddenly, my all > mail was there! :) Hrm, that's a bad behaviour of evolution. Maybe it is just a side-effect of the opened connections you mentioned below. > Additional note: when evolution was opening a zillion connections to imap+ > on gmail, if left in that state for 5 minutes or more, it was affecting my > desktop's performance -- at first I thought it was just gnome-shell, but > killing evolution immediately helped. Can be, I think, especially if it opens too many file descriptions (connections). I didn't notice anything like this myself, though. Anyway, opening too many connections is really a bug. The imapx options have entry for limiting opened connections (I think it still does nothing, though). Would you mind to try to identify what was going wrong here, or you want close this bug report? To identify it it'll need at least a backtrace of running evolution in the "too many connections opened", to see whether it is stuck somewhere or the connections are left opened accidentally. Checking with lsof how many connections to gmail are opened may help too, though I do not see these easily identifiable on my machine.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 'version' of '17'. 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 prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life. 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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.