[Dovecot] Icedove (Thunderbird) crashes when reading IMAP messages

[Bill Cole]

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 at 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 at scconsult.com