At 11:18 AM -0700 4/3/08, Cam Ellison wrote:
This is a Debian lenny/sid installation. Dovecot has been installed on it for over a year, with no problems. Lately (i.e. the past few months), if I attempt to read a message, Icedove crashes. It does not do this when I read a message downloaded from the ISP's POP3 server (not that I do this very often - almost all my mail goes through Dovecot).
A mail client that crashes when reading mail is either broken is running on a broken system, and fixes *to what is broken* are the right way to prevent that even if there happens to be something odd and/or wrong on the server side that is triggering the crash. This is not a Debian testers or Icedove list, so you are likely to not get a fix for your problem here. It is also not likely that configuring Dovecot differently will be able to work around such a crash, as Dovecot doesn't seem to notice that anything at all is wrong. However evil the data flowing from Dovecot to Icedove might have been, a crash would not be a reasonable response, with the possible exceptional case of Icedove trying to handle what it got from Dovecot and being mistreated by the OS in doing so. Even in that case the fix would not be in Dovecot.
That said...
At 4:45 PM -0700 4/3/08, cam@ellisonpsychology.ca wrote:
I hate replying to my own emails, but progress is being made. I now have rawlogs. What do I do with them? How do I make sense of them?
Dovecot rawlogs come in pairs: the <date>-<time>-<pid>.in files are what the client sent in, the <date>-<time>-<pid>.out are what the server sent out as response. Each of those pairs of files is from one session between the client and the server, and IMAP clients will often run multiple sessions in parallel. They also sometimes hold a session open in IDLE mode, waiting to be notified by the server of a change to a mailbox.
Many people on this list speak IMAP and could help explain the chat between the client and server if you need a deep explanation, but in all likelihood the real use of those logs would be in the bug report opened with the Icedove and/or Thunderbird developers. Just the tails of a pair of logfiles that are from a session where Icedove crashed should be adequate to show what Icedove was asking for and what Dovecot was sending back when Icedove crashed, although a clear path to *why* it crashed probably isn't in those logs.
I have more or less reverted to the original setup with icedove, but it now crashes more readily than before. I think it's important to note that the only problem I have with squirrelmail, which I'm now using, and which accesses dovecot only, is when a folder is too large for memory. No crashes, no mis-filing, no problems basically.
You haven't mentioned any memory-relevant details about your system, but the phrase 'folder is too large for memory' sounds a bit suspicious. How many messages would that be? You also mentioned that fiddling with the Icedove configuration caused trouble in KDE, specifically KMail, and that does not make a lot of sense either *unless* you have a deeper problem on your system like simple memory starvation. That could be enough to cause the crash with a segfault under the right sort of stress. Maybe I missed you saying otherwise, but it sounds like you are running Dovecot on the same machine that you are using Icedove on, and that might be adequate to spike memory demand for both at the same time and hence for the system as a whole. If you are running the whole system tight on memory, that sort of simultaneous spike could mean that one of the processes demanding more won't be able to get it, and sometimes that will trigger a segfault. You may simply be asking this machine to do more than it can, although you'd have to look at the memory/swap configuration and usage to know for sure. Since you are running an unstable/test OS distribution, it would also not be particularly shocking if something on that system had a memory leak that is the real root cause.
--
Bill Cole
bill@scconsult.com