[Dovecot] Icedove (Thunderbird) crashes when reading IMAP messages
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).
I am now having to read email with KMail, but cannot send from it - that's another story.
Googling for the past month or so reveals nothing: there seems to be no bug filed for this, and indeed I think it is an odd communication problem with dovecot that has not been seen before.
Has anyone any experience with this, or any ideas how I should go about resolving it? I have not done so (because I don't know how to use the data, not being a coder), but can run strace and/or valgrind on icedove if that will help.
Thanks in advance
Cam
-- Cam Ellison Ph.D. R.Psych. #01417
Cam Ellison & Associates Ltd. Management Psychology
3446 Beach Avenue Roberts Creek BC V0N 2W2
Phone: 604.885.4806 Fax: 604.885.4809 Cell: 604.989.0635
On Thu, 3 Apr 2008, 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).
Have you tried creating a new account with the same settings as the normal Dovecot account? Maybe Icedove/Thunderbird has corrupted some local data.
If it persists, then get a raw log from Dovecot and let's see what has to be done from there.
-- Asheesh.
-- An age is called Dark not because the light fails to shine, but because people refuse to see it. -- James Michener, "Space"
Asheesh Laroia wrote:
On Thu, 3 Apr 2008, 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).
Have you tried creating a new account with the same settings as the normal Dovecot account? Maybe Icedove/Thunderbird has corrupted some local data.
Icedove won't allow that - I have just tried it. Interestingly, I was able to read your message with no problems, but Icedove crashed when I attempted to read a recent message in another folder. I expect you may be right about corruption.
If it persists, then get a raw log from Dovecot and let's see what has to be done from there.
As to getting a log, this is a Debian installation, and everything goes to syslog. I have made the necessary change in dovecot.conf, and will see what I can generate. No luck so far with valgrind: I must be setting it up wrong.
Thanks for the help
Cam
-- Cam Ellison Ph.D. R.Psych. #01417
Cam Ellison & Associates Ltd. Management Psychology
3446 Beach Avenue Roberts Creek BC V0N 2W2
Phone: 604.885.4806 Fax: 604.885.4809 Cell: 604.989.0635
Have you tried creating a new account with the same settings as the normal Dovecot account? Maybe Icedove/Thunderbird has corrupted some local data.
I moved the entire directory out of mozilla-thunderbird, deleted the account, and then created a new one. Performance is now even worse. There are few things that I can do without triggering a crash. At the moment I'm using Squirrelmail, since there's something wrong with KDE: KMail now fails to start.
If it persists, then get a raw log from Dovecot and let's see what has to be done from there.
Let's do that. I need a pointer or two. I assume that protocols = imap is equivalent to protocol { ...imap }. Is this correct? I shall try it and see what happens, but I don't want to make things worse.
Thanks
Cam
-- Cam Ellison, PhD RPsych (BC #01417) Cam Ellison & Associates Ltd. 3446 Beach Avenue Roberts Creek BC V0N 2W2 Phone 604.885.4806 Fax 694.885.4809 Cell 604.989.0635
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?
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.
Cheers
Cam
-- Cam Ellison, PhD RPsych (BC #01417) Cam Ellison & Associates Ltd. 3446 Beach Avenue Roberts Creek BC V0N 2W2 Phone 604.885.4806 Fax 694.885.4809 Cell 604.989.0635
On Thu, 3 Apr 2008, 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?
Well, they're transcripts of what Dovecot said to Icedove and vice versa. Is there some pattern? Maybe Dovecot sends Icedove a message called "YOU WEASEL" and Icedove crashes in response.
But truth be told, I think that this is unrelated to Dovecot.
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.
Can you try adding a new user to your system, and then running Icedove with this configuration?
I know it looks like I'm grasping at straws here, but I vaguely remember similar Icedove issues and them seeming very strange. (And what version of Icedove? "dpkg -l icedove" should say.)
-- Asheesh.
-- Will Rogers never met you.
Charles Marcus wrote:
On 4/3/2008, Cam Ellison (cam@ellisonpsychology.ca) wrote:
Dovecot has been installed on it for over a year, with no problems.
What version?
1.0.13
I think it's some weird communication thing between icedove and dovecot. Valgrind (memcheck) gives me this:
/usr/lib/icedove/run-mozilla.sh: line 131: 18624 Segmentation fault "$prog" ${1+"$@"}
The relevant parts of the dovecot log are:
dovecot: Apr 03 13:46:25 Info: auth(default): new auth connection: pid=18723 dovecot: Apr 03 13:46:26 Info: auth(default): client in: AUTH 1 PLAIN service=IMAP secured lip=24.207.104.15 rip=24.207.104.15 dovecot: Apr 03 13:46:26 Info: auth(default): client out: CONT 1 dovecot: Apr 03 13:46:26 Info: auth(default): client in: CONT<hidden> dovecot: Apr 03 13:46:26 Info: auth(default): pam(cam,24.207.104.15): lookup service=dovecot dovecot: Apr 03 13:46:26 Info: auth(default): client out: OK 1 user=cam dovecot: Apr 03 13:46:26 Info: auth(default): master in: REQUEST 51 18653 1 dovecot: Apr 03 13:46:26 Info: auth(default): passwd(cam,24.207.104.15): lookup dovecot: Apr 03 13:46:26 Info: auth(default): master out: USER 51 cam system_user=cam uid=1000 gid=1000 home=/home/cam dovecot: Apr 03 13:46:26 Info: imap-login: Login: user=<cam>, method=PLAIN, rip=24.207.104.15, lip=24.207.104.15, secured dovecot: Apr 03 13:46:26 Info: IMAP(cam): Effective uid=1000, gid=1000, home=/home/cam dovecot: Apr 03 13:46:26 Info: IMAP(cam): maildir: data=/var/mail/cam/Maildir dovecot: Apr 03 13:46:26 Info: IMAP(cam): maildir: root=/var/mail/cam/Maildir, index=/var/mail/cam/Maildir, control=, inbox= dovecot: Apr 03 13:46:28 Info: auth(default): new auth connection: pid=18728 dovecot: Apr 03 13:46:28 Info: auth(default): client in: AUTH 1 PLAIN service=IMAP secured lip=24.207.104.15 rip=24.207.104.15 dovecot: Apr 03 13:46:28 Info: auth(default): client out: CONT 1 dovecot: Apr 03 13:46:28 Info: auth(default): client in: CONT<hidden> dovecot: Apr 03 13:46:28 Info: auth(default): pam(cam,24.207.104.15): lookup service=dovecot dovecot: Apr 03 13:46:28 Info: auth(default): client out: OK 1 user=cam dovecot: Apr 03 13:46:28 Info: auth(default): master in: REQUEST 52 18723 1 dovecot: Apr 03 13:46:28 Info: auth(default): passwd(cam,24.207.104.15): lookup dovecot: Apr 03 13:46:28 Info: auth(default): master out: USER 52 cam system_user=cam uid=1000 gid=1000 home=/home/cam dovecot: Apr 03 13:46:28 Info: imap-login: Login: user=<cam>, method=PLAIN, rip=24.207.104.15, lip=24.207.104.15, secured dovecot: Apr 03 13:46:28 Info: IMAP(cam): Effective uid=1000, gid=1000, home=/home/cam dovecot: Apr 03 13:46:28 Info: IMAP(cam): maildir: data=/var/mail/cam/Maildir dovecot: Apr 03 13:46:28 Info: IMAP(cam): maildir: root=/var/mail/cam/Maildir, index=/var/mail/cam/Maildir, control=, inbox= dovecot: Apr 03 13:46:33 Info: IMAP(cam): Disconnected in IDLE dovecot: Apr 03 13:46:33 Info: IMAP(cam): Disconnected in IDLE dovecot: Apr 03 13:46:40 Info: auth(default): new auth connection: pid=18764 dovecot: Apr 03 13:46:40 Info: auth(default): client in: AUTH 1 PLAIN service=IMAP secured lip=24.207.104.15 rip=24.207.104.15 dovecot: Apr 03 13:46:40 Info: auth(default): client out: CONT 1 dovecot: Apr 03 13:46:40 Info: auth(default): client in: CONT<hidden> dovecot: Apr 03 13:46:40 Info: auth(default): pam(cam,24.207.104.15): lookup service=dovecot dovecot: Apr 03 13:46:40 Info: auth(default): client out: OK 1 user=cam dovecot: Apr 03 13:46:40 Info: auth(default): master in: REQUEST 53 18728 1 dovecot: Apr 03 13:46:40 Info: auth(default): passwd(cam,24.207.104.15): lookup dovecot: Apr 03 13:46:40 Info: auth(default): master out: USER 53 cam system_user=cam uid=1000 gid=1000 home=/home/cam dovecot: Apr 03 13:46:40 Info: imap-login: Login: user=<cam>, method=PLAIN, rip=24.207.104.15, lip=24.207.104.15, secured dovecot: Apr 03 13:46:40 Info: IMAP(cam): Effective uid=1000, gid=1000, home=/home/cam dovecot: Apr 03 13:46:40 Info: IMAP(cam): maildir: data=/var/mail/cam/Maildir dovecot: Apr 03 13:46:40 Info: IMAP(cam): maildir: root=/var/mail/cam/Maildir, index=/var/mail/cam/Maildir, control=, inbox= dovecot: Apr 03 13:46:51 Info: auth(default): client in: AUTH 1 PLAIN service=IMAP secured lip=24.207.104.15 rip=24.207.104.15 dovecot: Apr 03 13:46:51 Info: auth(default): client out: CONT 1 dovecot: Apr 03 13:46:51 Info: auth(default): client in: CONT<hidden> dovecot: Apr 03 13:46:51 Info: auth(default): pam(cam,24.207.104.15): lookup service=dovecot dovecot: Apr 03 13:46:51 Info: auth(default): client out: OK 1 user=cam dovecot: Apr 03 13:46:51 Info: auth(default): master in: REQUEST 54 16801 1 dovecot: Apr 03 13:46:51 Info: auth(default): passwd(cam,24.207.104.15): lookup dovecot: Apr 03 13:46:51 Info: auth(default): master out: USER 54 cam system_user=cam uid=1000 gid=1000 home=/home/cam dovecot: Apr 03 13:46:51 Info: imap-login: Login: user=<cam>, method=PLAIN, rip=24.207.104.15, lip=24.207.104.15, secured dovecot: Apr 03 13:46:51 Info: IMAP(cam): Effective uid=1000, gid=1000, home=/home/cam dovecot: Apr 03 13:46:51 Info: IMAP(cam): maildir: data=/var/mail/cam/Maildir dovecot: Apr 03 13:46:51 Info: IMAP(cam): maildir: root=/var/mail/cam/Maildir, index=/var/mail/cam/Maildir, control=, inbox= dovecot: Apr 03 13:46:51 Info: auth(default): new auth connection: pid=18774
The above does not say much to me, and I cannot find a setting in dovecot.conf to have it be any more informative.
Thanks for the help
Cam
-- Cam Ellison Ph.D. R.Psych. #01417
Cam Ellison & Associates Ltd. Management Psychology
3446 Beach Avenue Roberts Creek BC V0N 2W2
Phone: 604.885.4806 Fax: 604.885.4809 Cell: 604.989.0635
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
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. <snip> Even in that case the fix would not be in Dovecot.
I have thought so from the beginning, but lacking full knowledge, I wanted to eliminate as much as I could from consideration.
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.
That seems to be the case - once I paired the log statements, it was clear that the communication between the two was OK. In fact, Dovecot was in IDLE mode when Icedove crashed, consistently.
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.
Well, they're definitely going to come in handy. :-)
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?
A couple of thousand. Actually, the memory thing was a red herring, and I should not have mentioned it. My laptop, which I use only when away from the office, has half a gig. Squirrelmail tries to read everything into memory, and there's a point past which it won't go.
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.
The KMail problem was solved by careful upgrading - I say "careful" because it meant avoiding bugs in related software. It now works fine, except that it can't cope with sending email either through my ISP or through Exim. Another problem to solve. The ISP is having problems of its own, with regard to mail.
Anyway, I purged Icedove, installed Tbird from scratch, and though the crashes no longer occur, I cannot send from it either, so it's back to Squirrelmail.
Thank you for the insight, and depth of discussion. At least I know more than I did 3 hours ago,
Cam
-- Cam Ellison, PhD RPsych (BC #01417) Cam Ellison & Associates Ltd. 3446 Beach Avenue Roberts Creek BC V0N 2W2 Phone 604.885.4806 Fax 694.885.4809 Cell 604.989.0635
participants (5)
-
Asheesh Laroia
-
Bill Cole
-
Cam Ellison
-
cam＠ellisonpsychology.ca
-
Charles Marcus