Re: [Evolution] BUG: frozen while looking up new mail

[Jeffrey Stedfast <fejj ximian com>]

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  -  evolution lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution
> -- 
> Florin Andrei
>
> http://florin.myip.org/
>
> _______________________________________________
> evolution maillist  -  evolution lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com