Created attachment 661685 [details] Fancy status bar. I've recently upgraded to FC18 and now having a bunch of questions (bug-reports). 1) Why does it take *up to* 1-2 minutes (sometimes only a few seconds) to write a user interface state to the disk ? (It's regularly happening and forces me to run killev because it locks up every other task within Evolution). 2) And related to 1) Why does it end in catching a lot of "unknown processes" ? Which increases all few seconds by 1 in the status bar ? Does it say, that Evolution doesn't know what it does ? Is this software still reliable for me as end user ? 3) And related to 1) and 2) How does this improve my Evolution and mailing experiences ? Or better asked, how will this improve my experiences once FC18 final shows up - in say - x < 3 weeks ? .... 4) As a side note. Why is there a mixture of XML and INI type of files showing up in the configurations section ? I recall that Evolution wanted to get away from this by switching from gnome-config to bonobo-config, later to gconf ? Now back to a mixture of XML and INI ? I do hope, that this is just temporarily due to the transition from bonobo components. Still it looks awful to have a mixture of XML files and plain INI files. It looks like the maintainer can't settle to something.
Thanks for a bug report. I cannot answer properly any of the 1)-3). To be able to do that I need a backtrace of evolution, to see what it tries to do. I only know that the "Saving user interface" is an activity piled in a queue of activities, and it is done only when those piled before it are done, which might mean when those "Unknown background operations" are done. If I may guess, then I think there happened something with password prompt, which prevents evolution from continuing with the activity. Could you install debugingo packages for evolution-data-server, evolution and any other evolution-* packages you use; make sure they will be of the same version as the binary packages. Then run evolution and get a backtrace of it, when it gets to this state, with this command: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt and also for an evolution-source-registry process. Could you stop all evolution processes (pkill evolution) and start evolution from scratch, whether it'll help? I'm not talking about restart, I'm talking about killing the running evolution* processes and starting them again in the same session. Finally, what are the configured account types you use, please? Were you asked for passwords for them, in case they require it? ad 4) Which do you mean? And does it matter? Those are internal evolution files, no matter whether they are INI-like, or XML, or plain text/binary files. XML is better for certain things than INI-like file. The effort you mention above was aimed to remove XML blobs from GConf, nothing more, and that's done.
Hello and thanks for the quick reply. (In reply to comment #1) > If I may guess, then I think there happened something with password prompt, > which prevents evolution from continuing with the activity. I should have mentioned the way how I use Evolution, that's true. I run my entire system on a USB Stick (RAGE XT 64 GB). This is still one of the fastest USB Sticks available which performs well on large files as well as performing good on small files (still up to 3-7 MB/s for smaller files). Last weekend I switched my FC17 system with latest updates to FC18 beta by upgrading it using YUM. The upgrade process worked perfectly and the system runs smoothly (considering that it is still a beta version with some glitches there and here). I run Evolution with a pop3 account on web.de which checks the mailboxes every 30 mins and download mails if available. I have about 30 different folders under the inbox folder and a large filter file that spreads all the mails into their correct folders. The entire evolution tar.bz2 file (that means the .config/evolution as well as .local/apps/evolution) folder are around 410 mb by now. This lead into many little tiny files (after the split from static mbox to single files). With Evolution 3.4 this all performed flawlessly well. No issues, no stuck in some "updating" processes or whatever. Speed and overall performance was no issue. With FC18 beta everything worked as usual once I ran Evolution 3.6. The mailboxes show up, mails are being pop'ed and so on. Sadly when going from one Inbox to another sub folder (in a tree), the now explained issues with stuck unknown processes and writing the interface state occurs. Sure even with 3.4 the status printed "writing interface state" when moving from one folder to another but it's just a matter of a part of a second. Please look at this screenshot here. It shows an ancient version of Evolution and only a few sub folders. But this should give you an idea what I like to express with using a tree. http://www.akcaagac.com/desktop/pictures/gnome/screenshot05.png With 3.6 the issue with getting stuck appears (... not always but quite often), when clicking from one folder to the next. Sometimes it goes on quickly and often it stays there for more than 1-2 minutes. Sometimes it continues after the 1-2 minutes and sometimes it simply stalls and does nothing (until killev is run). This is quite frustrating to say. But if I continue thinking then this might be an issue with some other background issue like the gnome indexing system ? (but it was there on FC17). And I also realized that the overall file-system performance when running nautilus for example is *NOTICEABLE MUCH SLOWER* than with FC17. Maybe it's related to the gnome VFS layer or the improved indexing system ? I can't say to say the truth. I need to note that I don't have a kernel with debug symbols anymore. The kernel is the same 3.6.x (now .10) which I use on FC17 as well. > Could you install debuging packages for evolution-data-server, evolution and > any other evolution-* packages you use Sure I could. I only hope they aren't big in size since my network connection is based on a tethering cell phone connection with limited bandwidth (7.2 kb/s max). Please tell me which repos I need to include. I ask this because when doing "yum install evolution-<TABTAB>" I only get normal packages and devel packages no debug stuff or similar things. > $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt > I'm not talking about restart, I'm talking about killing the running > evolution* processes and starting them again in the same session. Ok I will try this once I poll my emails again. > Finally, what are the configured account types you use, please? Were you > asked for passwords for them, in case they require it? POP3 @ web.de the PW is saved and no, I am not being asked to enter any passwords. It only occurs when switching from one folder to another (which triggers Evolution to save the interface status). Hope I was able to provide at least some first informations.
(In reply to comment #2) > Please tell me which repos I need to include. I ask this because when doing > "yum install evolution-<TABTAB>" I only get normal packages and devel > packages no debug stuff or similar things. I use command like this: $ yum install evolution-debuginfo evolution-data-server-debuginfo --enablerepo=updates-debuginfo > POP3 @ web.de the PW is saved and no, I am not being asked to enter any > passwords. It only occurs when switching from one folder to another (which > triggers Evolution to save the interface status). > > Hope I was able to provide at least some first informations. Thanks, this is helpful. You have only local folders, no remote in the folder tree, and you trigger the issue just by moving between local folders. It's rather unexpected, because working with local folders should be quick (evolution tries to rescan files in the folders, thus maybe that does the delay with your USB). Could you run evolution from terminal, when testing, whether it'll print any errors on console when you'll move between folders, and also check disk/IO/CPU activity with system monitor when evolution gets to this stuck state, please? I think that all is related. On the other hand, the 3.4 also used maildir as its underlying On This Computer provider for files/folders, thus maybe some recent change in the maildir code broke this? Let's see with the backtraces.
(In reply to comment #3) > I use command like this: > $ yum install evolution-debuginfo evolution-data-server-debuginfo > --enablerepo=updates-debuginfo --enablerepo=fedora-debuginfo did the trick here. > Thanks, this is helpful. You have only local folders, no remote in the > folder tree, and you trigger the issue just by moving between local folders. Exactly. > It's rather unexpected, because working with local folders should be quick > (evolution tries to rescan files in the folders, thus maybe that does the > delay with your USB). No, the USB is the fastest you get with USB2 spec, it runs even faster if connected to USB3 and reading speed is around 25mb/s. I assume that rescan files is a read only process rather than a read/write process. Something that I thought about was this. Maybe it is related to picture loading but I also had that issue with normal non image containing mails and once I ran killev and reloaded the mailbox the problems disappeared until appearance in another mail or box. My other thought was, that this could be an external component issue like glib or webkit maybe a thread related issue (deadlock or race condition) maybe a misplaced free(); somewhere. > Could you run evolution from terminal, when testing, Done. You find attached a very in depth archive with a few screenshots 2 transcript files (one for running evolution and one for backtracing). Also attached are plenty of backtrace files. Some contain alphabets to it like a, b, c, d, e, .... These are the nasty ones and usually ended with an killev. > whether it'll print any errors on console when you'll move between folders, > and also check disk/IO/CPU activity with system monitor when evolution gets > to this stuck state, please? No CPU issue, everything runs smooth. The output of evolution within the transcript file contains plenty of http://*.png|*.jpg images that it wanted to try loading from web. I replaced all http: and https: lines with <deleted> marks in case they contain encoded account informations. > I think that all is related. On the other hand, the 3.4 also used maildir as > its underlying On This Computer provider for files/folders, thus maybe some > recent change in the maildir code broke this? Exactly. There may be some changes. Maybe an external component - who knows ? > Let's see with the backtraces. Yeah please look at my attachment.
Created attachment 663113 [details] Backtraces, Screenshots, Logs
bt.txt - downloading images in 10 threads, main thread is drawing bt2.txt - one threads is searching for a sender's photo, 9 threads downloading images, main thread is drawing bt3.txt - one thread still waiting for an addressbook response, 7 threads waiting for it in a queue, 1 thread downloading images, main thread is drawing bt4a.txt - similar to bt3 bt4b.txt - similar to bt3 bt4c.txt - similar to bt3, only thread which was downloading the image is gone now bt4d.txt - similar to bt4c.txt, only main thread deep in gtk drawing, no X drawing like before bt4e.txt - similar to bt4c.txt bt4f.txt - similar to bt4c.txt, only the main thread is idle bt4g.txt - similar to bt4f.txt bt5.txt - stuck when trying to open an addressbook to search for a photo bt6.txt - similar to bt5.txt bt7.txt - similar to bt5.txt bt8.txt - similar to bt5.txt, only main thread is propagating window/widget resize bt9X.txt - similar to bt5.txt, still stuck in book open bt10.txt - still stuck in book open, with some images being downloaded and gtk+ drawing calls bt11X.txt - similar to bt5.txt bt12X.txt - managed to open a book, but waiting for its response, aka similar to bt4X.txt ----------------------------------------------------------------------------- From the above I'd say there is an address book which is causing trouble to evolution, by blocking the evolution-addressbook-factory process. Do you have any remote address books configured? Could you get _one_ backtrace of a running evolution-addressbook-factory process, when evolution gets to this stuck state, please? Couple notes: a) heavy drawing is caused by gtk+'s spinners, it's more trouble in gtk3.6.0, rather than in gtk3.6.1, but the later is not that great like gtk3.4.x. There is opened a bug [1] against Evolution for it upstream. This is causing high CPU usage too. b) Contact lookups, either for sender's photo or whether to download or not download images - please check what you have in Edit->Preferences->Mail Preferences->HTML Messages, section Loading Images - the option "Load images only in messages from contacts" is causing address book lookups. The Sender's photo option is on tab Headers, at the top. You can limit to search in local books only. c) Changing options from b) is only a workaround, there will be better to find out why evolution-addressbook-factory is not responding and fix it. There are opened several bug reports upstream, I would link the issue to another upstream bug report, but I cannot find it now. [1] https://bugzilla.gnome.org/show_bug.cgi?id=683867
> Do you have any remote address books configured? No! Only the local addressbook containing my own information and the picture. > Could you get _one_ backtrace of a running evolution-addressbook-factory > process, when evolution gets to this stuck state, please? Sure! Please tell me what debug stuff I need to download and how I should run gdb to get you the necessary backtrace. As a side note. Today I had to run killev 16 times due of things blowing up. This is quite frustrating. What I figured out once I ran killev was, that gnome-shell blew up one time. After digging around in my .local/share/evolution/addressbook/system folder I found one 10mb file called log.00000001 or something. This file was not there before I called Evolution. Could it be that some other software is trying to access something on my system using EDS ? And that thing, that tries to access it over EDS shedules something in a list causing Evolution to behave as it behaves now ? I packed the file named log.00000001 something to bz2 and reduced its size from 10mb to 300bytes. Maybe it gives you a hint ? I also figured out that within the same directory which stores the state.ini file, there was a null byte file called ".goutputstream-TDF9OW" which wasn't there before. This may be an orphaned file remaining from one of the killevs called.
Created attachment 664842 [details] The file log.00000001 something.
It's a database log file, it's OK it's there. For the backtrace, install debuginfo packages for evolution-data-server, and say for evolution itself too, though it's not used in the factory process, and make sure the versions match versions of binary packages (for example: rpm -qa | grep evolution | sort). Then get a backtrace with command: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution-addressbook-factory` &>bt.txt
(In reply to comment #9) > For the backtrace, install debuginfo packages for evolution-data-server, and > say for evolution itself too Ahh ok, they are the same as I already installed. I saw that you updated EDS so I took the chance to upgrade (+debuginfo). I also installed the glib2 debug stuff in case it may come handy. > Then get a backtrace with command: > gdb --batch --ex "t a a bt" -pid=`pidof evolution-addressbook-factory` &>bt.txt Ok here we go! I made a bunch of backtraces including some full backtraces. The first thing I realize is that the debuginfo are to my opinion worthless due to optimization flags. To get the best out of debugsymbols is to disable all kind of optimization. Using "-O0" during compile time would give the best results. No unlooping, no variable optimization and so on. This will result in a 1:1 bugreport including matching lines within the provided source code as well as disabling all the <optimized code> lines within the 'bt' ouput. Some compilers tend to hand over variables to CPU registers which makes a debug much more cumbersome. Anyways for my understanding I can't find anything wrong with the backtraces. A lot of jumps into PRETTY_CODE's. During the backtrace process I was stuck dealing with gdb and the output. During that time x>5 mins or so I realized that during that time I get plenty of these "unknown blah processes" in my status bar (close up to 10 or so) and they all seem to disappear after a LONG LONG time one by one. Either timeout or whatever. But be promised that I never had these issues with Evo 3.4 from FC17. This is the very first time. I also ran TOP in the background and realized that XOrg increases CPU time as soon as Evolution starts spitting out these informations within the status bar. Even Evolution increases its CPU time drasticly. I get nearly 40-55 % XOrg and around 40-45 % for Evo. But don't nail me on this, they are floating around upwards downwards, sometimes Evo needs more CPU than XOrg and so on.
Created attachment 665021 [details] Backtraces
Thanks for the update. It's strange, because all the backtraces shows the factory basically idle, while comment #5 backtraces of evolution show it stuck on waiting for the addressbook factory response. I guess you got other than the initial issue now.
Hello, I have the very similar problem with evolution in Fedora 18. Evolution stucks with a lot of waiting requests "Unknown background operations" and only killing helps. I have several IMAP accounts (currently, I leave only one for the test purposes) and one GNOME ONLINE ACCOUNT (GOA to gmail.com) is configured, but without transferring of Contacts, Calendar and e-mails. IMAP accounts are to private servers and everything works well before an upgrade to FC18. The versions are the following: rpm -qa | grep evolution | sort evolution-3.6.3-1.fc18.x86_64 evolution-bogofilter-3.6.3-1.fc18.x86_64 evolution-data-server-3.6.3-1.fc18.x86_64 evolution-data-server-debuginfo-3.6.3-1.fc18.x86_64 evolution-debuginfo-3.6.3-1.fc18.x86_64 evolution-ews-3.6.3-1.fc18.x86_64 evolution-mapi-3.6.3-1.fc18.x86_64 evolution-perl-3.6.3-1.fc18.x86_64 evolution-pst-3.6.3-1.fc18.x86_64 evolution-rspam-0.6.0-1.fc18.x86_64 evolution-rss-0.3.92-1.fc18.x86_64 evolution-spamassassin-3.6.3-1.fc18.x86_64 ffgtk-plugin-evolution-0.8.4-1.fc18.x86_64 libopensync-plugin-evolution2-0.22-26.fc18.x86_64 and I am going to add backtrace as an attachment.
Created attachment 687493 [details] Backtrace of stucked evolution
Thanks for the update. I'm trying to deal with this issue in an associated upstream bug report [1] for bug #888172, thus let's move there. The [2] contains a link for a test build which can be related, though I'm not fully convinced it will. [1] https://bugzilla.gnome.org/show_bug.cgi?id=691276 [2] https://bugzilla.gnome.org/show_bug.cgi?id=691276#c24 *** This bug has been marked as a duplicate of bug 888172 ***
*** Bug 908515 has been marked as a duplicate of this bug. ***