It happens regardless of folders. Some are empty, some have thousands of messages.
On Wed, 2004-03-03 at 12:54, Jeffrey Stedfast wrote: > how about the number of messages in the folder you were viewing when > this happened? > > Jeff > > On Wed, 2004-03-03 at 12:31 -0800, Florin Andrei wrote: > > > Well, i don't know. If approx 100 folders count as "a lot", then yes. > > > > But this never happens if i don't use IMAP. > > > > On Wed, 2004-03-03 at 12:20, Jeffrey Stedfast wrote: > > > might just be the message-list redrawing? that would explain the pango > > > calls. might also be the folder-tree redrawing with unread count updates > > > (or maybe the corba calls are causing a temporary freeze?) > > > > > > do you have a lot of folders or a lot of messages in the folder you are > > > viewing when it freezes? > > > > > > Jeff > > > > > > On Wed, 2004-03-03 at 12:49, Florin Andrei wrote: > > > > On Tue, 2004-03-02 at 23:55, Not Zed wrote: > > > > > > > > > > And yet the symptoms are the same: as long as Evo is accessing the IMAP > > > > > > server, it's solid frozen. Once it's done updating the Inbox, it works > > > > > > again. > > > > > > > > > Well how about that backtrace? Looks like your others must've been done > > > > > at the wrong time, i.e. after said lockup was over. > > > > > > > > I'll do my best to get another backtrace to you guys soon. > > > > > > > > > I thought you actually had a hard freeze. A hard freeze is one from > > > > > which it never recovers. A delay for a couple of seconds isn't a hard > > > > > freeze. > > > > > > > > That's probably my mistake, i didn't explain it clearly enough. > > > > > > > > It is not an unrecoverable problem. Evo gets frozen for a few seconds, > > > > while it's checking out the IMAP server. Once it's done with whatever's > > > > supposed to do there, it starts working again. > > > > > > > > >From a user's p.o.v., the application becomes unresponsive for like > > > > 3...5 seconds every time it's automatically checking for new email. > > > > Yet somehow all events triggered by user during that time are not lost: > > > > they're quickly executed in a split-second once the freeze is over. > > > > > > > > > It just sounds like your system is busy, and the kernel isn't coping > > > > > well for that instant, but thats just based on the info you've given us > > > > > so far. > > > > > > > > Nope, that's not the case. Other applications are working fine during > > > > that time, not only on my dual-CPU Fedora system, but also on the > > > > single-CPU RH9 machine (which is supposed to be less able to cope with > > > > CPU hogs, being a single-CPU and all...). > > > > Indeed there is a CPU usage spike when the freeze happens, and indeed > > > > Evolution is the process eating up cycles, but that does not affect > > > > other processes. I can use Mozilla or OpenOffice just fine during those > > > > 3...5 seconds while Evo is solid frozen. > > > > > > > > During the freeze, Evolution is eating up a whole CPU (the other CPU > > > > stays idle), exclusively in userspace. "top" does not reveal any system, > > > > irq or iowait usage due to Evo. The user cycles are at 100%, idle, > > > > system, iowait, etc. are at 0%. > > > > Once the freeze is over, the CPU usage gets back to normal. > > > > > > > > In any case, on both workstations i can (and do) use big CPU hogs while > > > > using the desktop - things like MPEG2 encoders, etc., which keep the > > > > CPUs flat on the ceiling for hours. The desktop sluggishness is barely > > > > noticeable, the apps are responsive and all is well (i can even listen > > > > to MP3 meanwhile). > > > > It would take a whole lot more than that to freeze those systems just > > > > because of the load. This is not the case with Evolution; it has, like, > > > > what? 5 or 6 threads? pfffft! that's nothing, that's how my video > > > > encoders (transcode + mjpegtools) usually run. > > > > > > > > And if "top" tells the truth, it is only one Evo thread that grabs a > > > > CPU. The other threads do not even show up in the first 10...20 lines > > > > (i'm using the "H" command to tell it to display threads). And it is the > > > > "main" (or "parent" or whatever) thread that does it - i looked at the > > > > PID with "top", then i did a "ps axmf" and identified it, it's PID > > > > 31246, which seems to be the parent: > > > > > > > > 31246 ? S 3:04 evolution > > > > 31247 ? S 0:00 \_ evolution > > > > 31248 ? S 0:00 \_ evolution > > > > 31249 ? S 0:00 \_ evolution > > > > 31252 ? S 0:00 \_ evolution > > > > 31254 ? S 0:00 \_ evolution > > > > > > > > If i'm not making sense, please excuse me, i'm not a programmer. > > > > > > > > At this point, i suspect the problem should be actually easy to > > > > reproduce. Just perform a vanilla Fedora Core 1 install, no custom libs > > > > or apps, no Ximian Gnome (but do select the Gnome package category when > > > > installing Fedora, of course), no nothing, setup a Cyrus IMAPd server > > > > somewhere, and configure Evolution to query the server every 60 seconds. > > > > I am not sure about vanilla RH9 installs - RH9 has Evo-1.2 but i'm not > > > > using that, i upgraded to Evo-1.4, and i'm seeing the same issues with > > > > it. I have no idea whether or not Evo-1.2 has the problem. > > > > > > > > Maybe the problem happens with other IMAP servers as well, i don't know. > > > > In any case, it does not look like an IMAP server problem. Even if it > > > > were, the IMAP client should not get DoS'ed no matter what the server > > > > does. > > > > > > _______________________________________________ > > > evolution maillist - [EMAIL PROTECTED] > > > http://lists.ximian.com/mailman/listinfo/evolution > > -- > > Florin Andrei > > > > http://florin.myip.org/ > > > > _______________________________________________ > > evolution maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/evolution > -- Florin Andrei http://florin.myip.org/ _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
