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.
