Re: [Evolution] Evo 1.4 -- Killing X?
- From: Jason 'vanRijn' Kasper <vR movingparts net>
- To: Bradley Alexander <storm tux org>
- Cc: Evolution List <evolution lists ximian com>
- Subject: Re: [Evolution] Evo 1.4 -- Killing X?
- Date: 08 Jul 2003 10:33:10 -0400
On Tue, 2003-07-08 at 08:05, Bradley Alexander wrote:
I have noticed an increasing problem of late, on my Debian/unstable
workstation. I'm running Evo 1.4.0 from deb from the Debian archive.
I have the same setup. Running 1.4.0-4 from debian sid. And yes, I've
seen what seems to be the same kind of problem. But mine typically
happens when I tell evolution to shut down. I've reported this to the
list in the last month (look for "evolution taking 5+ minutes"...). It
has never been figured out what was causing this horrible problem that
makes my system completely unusable until evo is done.
I have discovered that if I have more than one dictionary enabled,
things take a REALLY long time (like tabbing off of the To: text field
takes 2+ seconds), and if I only have one dictionary enabled, things
seem snappier. I've also noticed that since I've only enabled one
dictionary (I previously had American, British, and Canadian enabled),
my 5+ minutes of shutdown hell have become more like 1+ minutes.
Also, I've ran strace after strace on evolution shutting down, and have
captured what it's doing when I see X become completely unresponsive.
It doesn't look like evolution is directly doing anything. The only
weird thing that I see whatsoever is this:
before I shut evolution down, top shows XFree86 as using around 2k of
SHR memory. When X goes into throes and doesn't come out again for
minutes at a time, I see that it now is using around 40Megs of SHR
memory. I don't know what this means, but it doesn't seem good. =:/
Anyone?
The problem I have seen manifests itself in one of two ways. Either the
X process will run away on me (CPU pegs with the prime offender being
XFree86 at something like 99.7%. I can't get the display to come up at
the console and generally have to ssh in and kill X), or when working at
the console, I will do something and it will cause X to kick me out and
go back to an xdm login.
Have you tried waiting for it? Like I noted above, I've seen this and
have had to wait 5+ minutes some times for X to come back. I'm also
running a P4-1.8 G machine with 1G of RAM (I don't know how that
compares with your machine, but if it's not as robust, the 5+ minutes
may be more like 10+).
The thing that I have noticed several times is that the activity that
causes me to be kicked out when sitting at the console is clicking the
Send/Receive in Evo. I had it happen to me just this morning with one
Eterm and evo running. I am beginning to suspect that the runaway
processes (which generally happen overnight when evo is running as
opposed to during the day when it is not) is also evo autochecking mail.
Has anyone seen behavior similar to this? Is there a fix for it?
I sure hope so!! Please keep the list updated, since I'd give money to
not have to go through minutes at a time of a completely useless
computer.
Thanks,
--
,-----------------------------------------------------------------//
| Jason 'vanRijn' Kasper :: Numbers 6:22-26
`
| All brontosauruses are thin at one end, much MUCH thicker
| in the middle, and then thin again at the far end. That is
| the theory that I have and which is mine, and what it is too.
,
| bash$ :(){ :|:&};:
`----------------------//
__________________________________________________________________________
Disclaimer: This e-mail message is intended only for the personal use of
the recipient(s) named above. If you are not an intended recipient, you
may not review, copy or distribute this message. If you have received this
communication in error, please notify us immediately by e-mail and delete
the original message.
This e-mail expresses views only of the sender, which are not to be
attributed to Rite Aid Corporation and may not be copied or distributed
without this statement.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]