GNOME Bugzilla – Bug 344196
evolution-connector-2.6.2 causes massive CPU usage, instability
Last modified: 2006-09-28 16:51:15 UTC
Please describe the problem: I upgraded to evolution-connector-2.6.2 yesterday, and something seems to be broken in the new release. When I opened evolution after the upgrade, I noticed that it was using almost 100% of the CPU. I tried closing evolution, but the program hung when I selected "Quit" under the "File" menu. In order to get evolution to close, I had to use the "kill" command on the command line. Even after I killed evolution, I noticed that the "evolution-exchange" process was still running, and it was still consuming almost 100% of the CPU. This suggested that it might be a problem with evolution-connector, so I tried removing all exchange accounts from my list of accounts in evolution. Once I removed my exchange accounts, I had no further problems, which suggests to me that there is indeed a problem with evolution-connector-2.6.2. Steps to reproduce: Open evolution version 2.6.2 with evolution-connector version 2.6.2 installed and try to update an exchange account in evolution. Actual results: See above. Expected results: Evolution should not use 100% of the CPU under normal circumstances, and it should not hang upon exitting. Does this happen every time? Yes. Other information:
Please provide the gdb traces of all the threads of evolution-exchange process, when it hogs CPU. See http://live.gnome.org/GettingTraces for details.
I started evolution in gdb, and waited until it started hogging CPU. When that happened, the program became non-responsive, so I killed via the command line. I obtained the following backtrace in gdb after killing evolution. I hope this is helpful. Let me know if I should have done this differently. (gdb) thread apply all bt
+ Trace 68827
Thread 1 (Thread -1209133376 (LWP 3511))
As I noted in the earlier bug report, after I kill evolution, evolution-exchange begins to hog CPU. (Before I killed the original evolution process, it was evolution-2.6 that was using the CPU.) So I attached the running evolution-exchange process to gdb and then killed evolution-exchange from the command line. I obtained the following stack trace. Again, please let me know if this information is not helpful, or if I should have done this differently. (gdb) thread apply all bt
+ Trace 68828
Thread 1 (Thread -1208633664 (LWP 3535))
*** Bug 344879 has been marked as a duplicate of this bug. ***
*** Bug 344656 has been marked as a duplicate of this bug. ***
A little more info: I discovered the 'evolution 2.6.2 doesn't work with exchange on FC5' problem several others have reported, here and on the FC5 lists. Can I just add that I have compiled 2.6.2 from source, and the symptoms are the same as Fedora's version; also 2.7.2.1 has exactly the same issues. What I see is: * Start evo and it times out connecting to exchange * Meanwhile evolution-exchange is downloading hundreds of Mb of anything I have read access to on the exchange server. I assume the second is the problem. What has changed I don't know, but it is certainly my impression that there is far more public stuff being locally cached than before. Help please! Bill
Ah...so CVS head doesn't time out. And so after 20 minutes, connected directly to the network, it is able to run. From runing E2K_DEBUG on the exchange process it spends the time downloading all these public messages. Cheers, Bill
There is also some kind of problems with attachments. I noticed that when sending attachments through evolution-exchange the destination gets the files corrupted. I tried sending an Excel file created with open office, it wouldn't open on Windows. Then I tried copying the very same file through FTP and it worked fine. I tried sending the same file through my POP account and it worked fine too. Maybe this is a related problem or we are talking about different bugs in the same release.
the problem in comment #8 is different, can you file a separate bug for that? And if possible please attach the file that is getting corrupted while sending through Evolution. with the evolution you built, are you seeing the same high CPU usage? If yes, There are 2 patches gone in after 2.6.2 release, on 2006-06-02 and 2006-06-15, by "Jeffrey Stedfast" Please build with those patches and then try using Evolution.
To be honest, I'm not sure that the bug described in comment 6 is the same thing that I'm seeing. I don't see any indication that evolution "times out" when it attempts to connect to exchange. And there is definitely no network activity when evolution (or evolution-exchange) hang and start using large amounts of CPU. I wonder if we're seeing different issues here. Are you positive that evolution-exchange is downloading "hundreds of Mb of anything I have read access to on the exchange server"?
William Lovaton: Raise a new bug for attachment issue, i did verify in our setup here with a file of 3 MB xls file created using Open office, sent from evolution to a user using Outlook. Did not see any issue as mentioned in comment #8. What is the size of attachment in which you saw the problem mentioned ? would it be possible to attach that file in bugzilla ?
Hello all, We may well have several bugs mixed up. Or not. My symptoms are not that the network is overload - it takes 20 minutes to download 300Mbyte files on a 100Mbit/s link. The CPU is also fairly busy for the first few minutes. I just deleted two files, and then watch what happened to them on start .evolution/exchange/XXXXX/public/subfolders .evolution/mail/exchange/XXXXX/personal/subfolders I ran 3 different versions: public mail Evo-2.6.1 (new shown) 1Mb 20Mb Evo-2.6.1 (a bit later) 1Mb 83Mb Evo-2.6.2 161Mb Not made Evo head (after a bit) 161Mb 76Mb Note that I also made a test account, ran the connect-to-exchange wizard but did not set any local store settings, and evo 2.6.2 was identical to above behaviour. So I conclude that these public folders are downloaded each and evry time evo starts, no attempt to check if it was already done. And I don't want them - I never used them. Bill
Created attachment 67791 [details] [review] Proposed fix The fix keeps the marshal->inptr and marshal->in->data pointers in sync always, as a mismatch can lead to wrong avail computation and subsequent read from invalid memory location. I don't have access to exchange server and haven't tested the fix. Please someone help me by testing the fix. Thanks.
I tried the patch. The changes to do_read got rejected against the FC5 sources, so I did them manually. I then found that do_read was infinite looping because camel_read was returning -1. I changed the while condition to: } while (n > 0 && nread < *len && errno != EINTR); which apparently stopped this infinite loop. However, it doesn't fix my original problem with evolution hanging. evolution_exchange is in S1 state, not R.
Eric Bair, Your issue seems to be different than this bug. This bug is about Evolution hogging CPU, but what you are seeing is evolution-exchange-storage using high CPU. It is better if you file a different bug. Discussing 2 problems in one bug makes it confusing. In your bug report, please paste the gdb traces for evolution-exchange-storage when it start using high cpu.
(In reply to comment #15) > Eric Bair, > Your issue seems to be different than this bug. > This bug is about Evolution hogging CPU, > but what you are seeing is evolution-exchange-storage > using high CPU. It is better if you file a different bug. > Discussing 2 problems in one bug makes it confusing. > In your bug report, please paste the gdb traces for > evolution-exchange-storage when it start using high cpu. > It sounds like there's some confusion going on. I was the one who filed this bug report initially, and it does involve evolution hogging CPU. However, when this happened, I tried to kill evolution at the command line. After I killed off evolution, then evolution-exchange-storage continues to run and consume nearly 100% of the CPU. I posted the gdb traces for both evolution and evolution-exchange-storage in an earlier comment on this bug. If you believe that this is the result of two independent bugs in the two separate programs, I'm happy to file a second bug report. However, I'm inclined to believe that these two issues are one and the same. I don't have any problems with evolution hogging CPU when I delete all my exchange accounts, so I'm inclined to believe that the bug is related to evolution-connector.
(In reply to comment #14) > I tried the patch. The changes to do_read got rejected against the FC5 sources, > so I did them manually. I then found that do_read was infinite looping because > camel_read was returning -1. I changed the while condition to: > > } while (n > 0 && nread < *len && errno != EINTR); > > which apparently stopped this infinite loop. However, it doesn't fix my > original problem with evolution hanging. evolution_exchange is in S1 state, not > R. > Thanks for trying the patch. The patch is to fix crash of evolution process (not evolution-exchange-storage process) similar to the traces of the new bug #345558. I think the evolution trace in this bug is similar to http://bugzilla.gnome.org/show_bug.cgi?id=345558#c2 since the pointer corruption can cause crashes at different places. We may still need additional fixes to solve the problem fully.
Hello all, I too tried the patch, but applied it to the CVS head, where it did not need editing. However, it did not seem to do anything. I mean the public folders are still downloaded before anything else happens. This means a huge wait. Bill
(In reply to comment #18) > Hello all, > I too tried the patch, but applied it to the CVS head, where it > did not need editing. However, it did not seem to do anything. I > mean the public folders are still downloaded before anything else > happens. This means a huge wait. > Bill > Thanks for trying the patch. But it doesn't attempt to fix the problem of downloading huge data from the exchange server. It fixes a crash of evolution due to a pointer corruption. Please see comment #17.
Looking at the proposed change do do_read, there's another problem - the camel_read can go off the end of the buffer. My change was: if ((n = camel_read (marshal->fd, buf, len-nread)) > 0) Unfortunately, this still didn't fix my problem. So, looking at the developer's page, I found the E2K_DEBUG environment variable. Looking at the resulting logs, it doesn't appear to me that evolution ever actually attempts to read my exchange mail. The "Scanning folders in Exchange server" message appears in the status bar, and stays there for a long time. If I attempt to open that account folder, a second "Scanning folders in Exchange server" message will appear. If I attempt to close the applications using the window's X, only one message goes away. I have to manually kill the application. Here's the log from evolution-exchange: Evolution Exchange Storage up and running E2K_DEBUG=1 cal = 0x8ddaf80 GET /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x8e1c000 @ 1150989492 401 Unauthorized E2k-Debug: 0x8e1c000 @ 1150989492 GET /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x8e1c000 @ 1150989492 [restarted] 200 OK E2k-Debug: 0x8e1c000 @ 1150989492 PROPFIND /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x8e1c060 @ 1150989492 207 Multi-Status E2k-Debug: 0x8e1c060 @ 1150989492 SEARCH /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x8e1c0c0 @ 1150989492 207 Multi-Status E2k-Debug: 0x8e1c0c0 @ 1150989492 SEARCH /exchange/spaavola/Sync Issues/ HTTP/1.1 E2k-Debug: 0x8e1c120 @ 1150989492 207 Multi-Status E2k-Debug: 0x8e1c120 @ 1150989492 SEARCH /exchange/spaavola/NON_IPM_SUBTREE/Shortcuts HTTP/1.1 E2k-Debug: 0x8e1c180 @ 1150989492 207 Multi-Status E2k-Debug: 0x8e1c180 @ 1150989492 PROPFIND /exchange/spaavola/Calendar/ HTTP/1.1 E2k-Debug: 0x8e1c1e0 @ 1150989492 207 Multi-Status E2k-Debug: 0x8e1c1e0 @ 1150989492 SUBSCRIBE /exchange/spaavola/Calendar/ HTTP/1.1 E2k-Debug: 0x8e1c240 @ 1150989492 401 Unauthorized E2k-Debug: 0x8e1c240 @ 1150989492 SUBSCRIBE /exchange/spaavola/Calendar/ HTTP/1.1 E2k-Debug: 0x8e1c240 @ 1150989492 [restarted] SEARCH /exchange/spaavola/Calendar/ HTTP/1.1 E2k-Debug: 0x8e1c6a8 @ 1150989492 200 OK E2k-Debug: 0x8e1c240 @ 1150989492 207 Multi-Status E2k-Debug: 0x8e1c6a8 @ 1150989492 BPROPFIND /exchange/spaavola/Calendar/ HTTP/1.1 E2k-Debug: 0x8e1c708 @ 1150989492 207 Multi-Status E2k-Debug: 0x8e1c708 @ 1150989492 GET /exchange/spaavola/Calendar/{D1A1764B-7044-40B7-8C89-F0A705FE5BA1}.EML HTTP/1.1 E2k-Debug: 0x8e1c768 @ 1150989492 200 OK E2k-Debug: 0x8e1c768 @ 1150989492 GET /exchange/spaavola/Calendar/CC and IRS planned hardware and software implementation to support 40 images per second.EML HTTP/1.1 E2k-Debug: 0x8eec020 @ 1150989492 200 OK E2k-Debug: 0x8eec020 @ 1150989492 GET /exchange/spaavola/Calendar/CC speed for next build.EML HTTP/1.1 E2k-Debug: 0x8eec080 @ 1150989492 200 OK E2k-Debug: 0x8eec080 @ 1150989492 GET /exchange/spaavola/Calendar/Updated: Staff Meeting.EML HTTP/1.1 E2k-Debug: 0x8eec0e0 @ 1150989492 200 OK E2k-Debug: 0x8eec0e0 @ 1150989492 GET /exchange/spaavola/Calendar/{E352F4C6-4640-485B-B026-C6A3FEE68A32}.EML HTTP/1.1 E2k-Debug: 0x8eec140 @ 1150989492 200 OK E2k-Debug: 0x8eec140 @ 1150989492 GET /exchange/spaavola/Calendar/Analogic Holiday-2.EML HTTP/1.1 E2k-Debug: 0x8eec1a0 @ 1150989492 200 OK E2k-Debug: 0x8eec1a0 @ 1150989492 GET /exchange/spaavola/Calendar/Analogic Holiday.EML HTTP/1.1 E2k-Debug: 0x8eec200 @ 1150989492 200 OK E2k-Debug: 0x8eec200 @ 1150989492 GET /exchange/spaavola/Calendar/Iwill.EML HTTP/1.1 E2k-Debug: 0x8eec260 @ 1150989492 200 OK E2k-Debug: 0x8eec260 @ 1150989492 GET /exchange/spaavola/Calendar/All Hands.EML HTTP/1.1 E2k-Debug: 0x8eec2c0 @ 1150989492 200 OK E2k-Debug: 0x8eec2c0 @ 1150989492 GET /exchange/spaavola/Calendar/Jerome.EML HTTP/1.1 E2k-Debug: 0x8eec320 @ 1150989492 200 OK E2k-Debug: 0x8eec320 @ 1150989492 GET /exchange/spaavola/Calendar/HMC UI.EML HTTP/1.1 E2k-Debug: 0x8eec380 @ 1150989492 200 OK E2k-Debug: 0x8eec380 @ 1150989492 GET /exchange/spaavola/Calendar/FW: CC + SWIRS discussions.EML HTTP/1.1 E2k-Debug: 0x8e3f000 @ 1150989492 200 OK E2k-Debug: 0x8e3f000 @ 1150989492 GET /exchange/spaavola/Calendar/Best Pitch Choices for IQ and Recon Speed.EML HTTP/1.1 E2k-Debug: 0x8e3f060 @ 1150989492 200 OK E2k-Debug: 0x8e3f060 @ 1150989492 GET /exchange/spaavola/Calendar/AMS1600 Control Computer Spec, 21-00872 rev 02.EML HTTP/1.1 E2k-Debug: 0x8e3f0c0 @ 1150989492 200 OK E2k-Debug: 0x8e3f0c0 @ 1150989492 GET /exchange/spaavola/Calendar/Technical Orientation Meeting by Mike Welch and Robert French.EML HTTP/1.1 E2k-Debug: 0x8e3f120 @ 1150989492 200 OK E2k-Debug: 0x8e3f120 @ 1150989492 And a similar log from evolution: CalDAV Eplugin starting up ... (evolution-2.6:20518): camel-WARNING **: camel_exception_get_id called with NULL parameter. (evolution-2.6:20518): camel-WARNING **: camel_exception_get_id called with NULL parameter. GET /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x836b800 @ 1150989755 401 Unauthorized E2k-Debug: 0x836b800 @ 1150989755 GET /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x836b800 @ 1150989755 [restarted] 200 OK E2k-Debug: 0x836b800 @ 1150989755 PROPFIND /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x836b860 @ 1150989755 207 Multi-Status E2k-Debug: 0x836b860 @ 1150989755 SEARCH /exchange/spaavola/ HTTP/1.1 E2k-Debug: 0x836b8c0 @ 1150989755 207 Multi-Status E2k-Debug: 0x836b8c0 @ 1150989755 SEARCH /exchange/spaavola/Sync Issues/ HTTP/1.1 E2k-Debug: 0x836b920 @ 1150989755 207 Multi-Status E2k-Debug: 0x836b920 @ 1150989755 SEARCH /exchange/spaavola/NON_IPM_SUBTREE/Shortcuts HTTP/1.1 E2k-Debug: 0x836b980 @ 1150989755 207 Multi-Status E2k-Debug: 0x836b980 @ 1150989755
you have to do buf + nread - how would that ever go past the buffer??? ook a look into camel_read() and there's no errno that is recoverable, so no need to check errno against EINTR (which means the user cancelled the operation, meaning the connection is meant to be dropped) this loop should be ok I think: static gboolean do_read (CamelStubMarshal *marshal, char *buf, size_t len) { size_t nread = 0; ssize_t n; do { if ((n = camel_read (marshal->fd, buf + nread, len - nread)) <= 0) break; nread += n; } while (nread < len); if (nread < len) { close (marshal->fd); marshal->fd = -1; return FALSE; } return TRUE; } also, why have do_read() return the number of bytes read? it's unneeded. do_read() is meant to read exactly the number of bytes requested - anything less will make it return FALSE and is irrecoverable.
Created attachment 67896 [details] [review] camel-stub-marshal.c diff vs. FC5 source
I like this patch. It fixes my typo, and fixes my hang problem. I've attached the diff against the FC5 source.
(In reply to comment #21) > also, why have do_read() return the number of bytes read? it's unneeded. > do_read() is meant to read exactly the number of bytes requested - anything > less will make it return FALSE and is irrecoverable. > The problem I found was marshal->inptr and marshal->in->data weren't in sync always. We need to set marshal->inptr everytime marshal->in bytearray size is changed. But if do_read fails, either we can set the bytearray size to zero or to whatever we have actually read. I chose the later. We can change it to set the size to zero.
*** Bug 344391 has been marked as a duplicate of this bug. ***
Got the following trace from evolution-exchange-storage - not sure if this is still related. Have not been able to connect to exchange for a day or so. Constantly loosing connection to backend. (gdb) run Starting program: /usr/libexec/evolution/2.6/evolution-exchange-storage Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x4d2cb000 [Thread debugging using libthread_db enabled] [New Thread -1208772928 (LWP 3657)] [New Thread -1210872928 (LWP 3660)] Evolution Exchange Storage up and running [New Thread -1211139168 (LWP 3682)] [Thread -1211139168 (LWP 3682) exited] GLib-ERROR **: gmem.c:135: failed to allocate 1286380045 bytes aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1208772928 (LWP 3657)] 0x4d2cb402 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 69076
Rodney McKee, Yes this is a related issue.
*** Bug 345987 has been marked as a duplicate of this bug. ***
*** Bug 343516 has been marked as a duplicate of this bug. ***
I applied the patch: camel-stub-marshal.c diff vs. FC5 source And it fixed the problem. But now when new mail comes in, its not reflected in the inbox folder. The number of unread messages in the folder listing goes up, but the messages dont appear in the inbox folder until I restart evolution. Example: In the folder listing I would see: Inbox (2) But no new message in the inbox message listing on the right hand side. The two new messages would show up when I restart evolution.
Just applied the patch (first time at this), not sure I got the spec file just right, but it appeared to run the patch. Looks to be working fine. I have seen the problem Paul Faure was experiencing but that was on an unpatched system also used here. I do see new mail coming in, counter increasing and mail in the inbox.
(In reply to comment #11) > William Lovaton: Raise a new bug for attachment issue, i did verify in our > setup here with a file of 3 MB xls file created using Open office, sent from > evolution to a user using Outlook. Did not see any issue as mentioned in > comment #8. What is the size of attachment in which you saw the problem > mentioned ? would it be possible to attach that file in bugzilla ? > Hi, The problem happens sending any kind of attachment, I just tried sending 2 images I edited with gimp, the attachments got corrupted in the receiving end. Is anyone of the commenters of this bug seeing this problem?? Can anyone suffering evolution/exchange problems confirm this specific problem? If so, I'll open a new bug report. The problem is that I am reverting evolution due to several obligations at my workplace. For instance I can confirm comment #30 by Paul Faure, when new messages arrive I just can see the counter in the left side pane going up but the messages doesn't show up in the message list even if I try to send and receive several times. Closing and reopening evolution can be used as a workaround for me.
Spoke to soon, SOME mail is appearing but the counter is increasing to include others not seen in the inbox. Can confirm mail in the inbox using OWA session. Deleted folder also did not seem to empty until evolution was restarted.
with the new patch installed I now seem to have issues opening attachments not sure if this is still related to this issue or if I need to raise a new bug. It does not appear to be attachment specific as they have so far been .zip and .pdf attachments. (gdb) thread apply all bt
+ Trace 69124
Thread 1 (Thread -1208895808 (LWP 5675))
This is lame as I have nothing of technical value to add, except to say that I've also encountered this error. I connect to my corporate exchange account, and Connector proceeds to download 500MB(!) of data from the public folders. Ouch. And then I encountered the 100% cpu state. This problem is definitely critical since I can't really upgrade anything Gnome related without also upgrading evolution (which I don't quite understand why Gnome updates are dependent upon an application), but for anyone else encountering this error and needing to go back to the earlier version of Evolution to get up and running, here's the RPM command I issued (from the FC5 DVD) to downgrade: rpm -Uvh --oldpackage evolution-connector-2.5.92-1.i386.rpm evolution-data-server-1.5.92-1.i386.rpm gnome-panel-2.14.0-1.i386.rpm evolution-2.6.0-1.i386.rpm evolution-sharp-0.10.2-9.i386.rpm evolution-webcal-2.4.1-3.2.i386.rpm pilot-link-0.12.0-0.pre4.5.2.1.i386.rpm gnome-pilot-2.0.13-7.fc5.4.i386.rpm -Lee
William Lovaton, for the attachemnts getting corrupted issue, and unread count issue please open a new bugs. Rodney McKee, for hang during opening attachments, please open a new bug. This bug is about hang/crash/high CPU usage during loading Evolution and accessing mails.
*** Bug 332562 has been marked as a duplicate of this bug. ***
*** Bug 346938 has been marked as a duplicate of this bug. ***
Created attachment 68710 [details] [review] Partial fix Now resetting the byte array size when read fails. Is this change ok?
reopening, no idea why this is still set to NEEDINFO. lots fo duplicates, raising priority.
*** Bug 348037 has been marked as a duplicate of this bug. ***
*** Bug 348126 has been marked as a duplicate of this bug. ***
Created attachment 69498 [details] [review] Consolidated patch Can some here please test this consolidated patch which includes fejj's changes in comment #21 and Arun's changes in comment #39
*** Bug 348586 has been marked as a duplicate of this bug. ***
Wiliam Murray, Can you unsubscribe for the public folders that you are not using and see if it works for you? Downloading public folders issue is filed as http://bugzilla.gnome.org/show_bug.cgi?id=346728
*** Bug 348768 has been marked as a duplicate of this bug. ***
Hi Sushma, You asked whether I could unsubscribe from the public folders. They are not even listed! If I log in via OWA I see a whole section of public folder, but evo never showed them. So I don't know how to unsubscribe. I just compiled 2.6.3 - I'll report on that in the other bug.
It seems that I have the same problem. Tell me if I can help somehow. Unsubscribing from public folders doesn't work for me because the dialog for folder abos hangs after I try to access the ones on the exchange server.
I have the same high cpu/hang or crash sympton with evolution 2.6.2 and exchange. -- Dean Guenther guenther@wsu.edu
I applied the changes in the "consolidated" patch to the sources of the evolution-connector-2.6.2-1.fc5.4 RPM for FC5. The crashes stop but as others have noted, folder counts are updated while the contents are not.
I'm getting reports from Fedora Core users that this seems to be fixed now in evolution-exchange 2.6.3. Can one of the upstream developers confirm?
Can any one please test 2.6.3?
http://bugzilla.gnome.org/show_bug.cgi?id=349413 bug is about fetching new mails issue in 2.6.3
Created attachment 70623 [details] [review] One more patch related to this issue, submitted by vvaradhan@novell.com
s/replated/related
Not sure if I should say this here, but 2.6.3, whether direct from gnome or via fedora solve my 'hang at startup issues.
The new FC5 testing RPMs (2.6.3) fetch the crash problem for me, but it seems to lose connection to the Exchange server after a bit. I discovered this a few times when I had to restart evolution. This would be a separate bug I guess though.
Yup, the testing RPMS(2.6.3-1.fc5.5) are still borked. Seemed a bit more promising as the first test I sent myself actually incremented the new message count AND showed up in the folder. Subsequent messages did not, though.
My apologies - just read comment 53 about bug 349413. I will try the patch mentioned there and report back on that bug.
Anyone getting the "lost connection" error or "not fetching new message" problems, please try the patch in the comment #54 (same patch is attached to the bug #349413 also)
Well, I justed installed version 2.6.3 (evolution-connector-2.6.3-1.fc5.1, to be exact), and the problem seems to be solved on my system. I've had evolution running all day now, and it hasn't starting hogging CPU. Moreover, I've received several messages (including a message with an attachment) without any problems. At any rate, if I don't encounter any more problems in the next day or two, then I'm going to close this bug, because the problem seems to be fixed. If there is any reason that I should keep this bug open, please let me know.
Great news Eric, I'll try to update my Fedora Core 5 system as soon as my network problems let me and I'll confirm if the problems are solved in my case. Cheers.
I still have two problems: 1. Although the message count in the folder pane updates, after some time, the new messages do not show in my Inbox. I have to restart Evolution to see those messages. 2. Marking a message as spam fails to remove it from my Inbox. Point 2 is perhaps unimportant, and this bug is about cpu usage and instability, both of which are gone, however an important part of evolution - the ability to see a new e-mail when it arrives is still broken for me.
(In reply to comment #63) > I still have two problems: > 1. Although the message count in the folder pane updates, after some time, the > new messages do not show in my Inbox. I have to restart Evolution to see those > messages. > 2. Marking a message as spam fails to remove it from my Inbox. > > Point 2 is perhaps unimportant, and this bug is about cpu usage and > instability, both of which are gone, however an important part of evolution - > the ability to see a new e-mail when it arrives is still broken for me. > I can't reproduce the problem with messages not showing up in my inbox. I've been running evolution all day now, and messages that I received at the end of the day landed in my inbox without a problem. I haven't tried marking any messages as spam, but if that's not working, that should probably be a separate bug report anyway. I'll wait another day or two before I close this bug so that others can confirm that the massive cpu usage issue is gone. However, I'm increasingly confident that this issue is fixed.
Actually, as I reread the comments on this page, it sounds like everyone seems to agree that the cpu usage issue is fixed in 2.6.3. Some are still reporting problems with new messages not showing up in the inbox, but it appears that another bug report has already been filed on this issue. (Indeed, it's marked as fixed if I'm not mistaken.) Hence, I decided to go ahead and close this bug. If anyone finds that evolution is hanging and using huge amounts of CPU even after upgrading to 2.6.3, let me know, and I'll reopen it. Other issues mentioned on this thread should probably be filed as separate bug reports.
In reply to comment #63, 1. For the new mails fectching problem see the bug #349413 2. For the marking as spam problem, please file a separate bug.
Bug #257641 is about marking mails as junk.
*** Bug 349676 has been marked as a duplicate of this bug. ***
*** Bug 358152 has been marked as a duplicate of this bug. ***
*** Bug 357167 has been marked as a duplicate of this bug. ***