> > - the CAMEL_VERBOSE_DEBUG=1 log as suggested by Ettore (run > > "CAMEL_VERBISE_DEBUG=1 evolution-1.3" in a terminal) > > I will henceforth run evo this way. =:) I'll also log everything to a > file so that if it does happen, hopefully something useful will show up.
BTW if you upgrade to 1.4, the name you run is 'evolution' > > - run evolution-1.3 in gdb. Do some stuff, and quit so that things > > start going haywire. ctrl-c in gdb (if you can't ... that could be a > > problem, try running it from a virtual console perhaps), and run 'thread > > apply all bt' - this will show what code is running. > > > > well, again, when this happens, I can't do squat. Even though I start > evolution with "nice evolution", I can't even switch to a VC until evo's > done with its thing. Hmm, ok, that kinda sucks. > However, what you said makes perfect sense. Like I said, my hard drive > goes absolutely bonkers when this happens, and from what I've seen in > the past (when copying large files/moving files/removing files, etc.) > with XFS, it seems that XFS takes up massive amounts of CPU to do > massive amounts of disk work--to the point that the system becomes > unusable until it's done. Now, this was a while ago and I'm hoping that > XFS 1.2 has improved, but it just seems like this could be pointing to > XFS in some way (as a side-result of some fonky evo behavior). > > Now, there's a couple of things that I can think of, given the above, > that might lend itself to this lock-up. I normally don't "auto-expunge > trash on exit" with my $HOME/Maildir, which means, that I may have more > than several hundred entries in that vfolder at any given point in > time. It would seem that this might be problematic. What do you think? Naah shouldn't be. vFolders are just in-memory dynamic queries, nothing gets saved to disk. The main things that get saved to disk are the summary files - but these should be relatively small (compared to the size of the mailbox). Although if you have a lot of folders, it could write a lot of these out. > Also, I currently have bogofilter/procmail sending spam into a > $HOME/Maildir/Spam Maildir, and though evolution doesn't see this > automatically get updated when procmail puts mail there (while evo is > running), I'm wondering if it realizes that there's a whole bunch of > mail there since last time it looked (when it's going to shut down) and > tries to deal with them there? Like maybe it's updating the default, > un-deletable "Unmatched" VFolder, since the Spam Maildir is inside the > top-level Maildir that evo knows about? Hmm, yeah, i think it would probably re-sync at this time, and discover the new messages. Again if you have a lot, it could be a problem - but 5 minutes seems very excessive. _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
