On Wed, 2008-07-09 at 17:09 -0700, Dan Price wrote:
[327616] t_strconcat(str1 = 0x100e77f0 "tmp/compiler/venus/handoff/build20.2/CDROM/sol-x86/kits/j2sdk_1.4.2_08/patches/J2SE_Solaris_8_x86_Recommended/108994-44/SUNWcsr/.svn/prop-base", ...), line 335 in "strfuncs.c" [327617] mbox_list_next(ctx = 0x80f6348), line 273 in "mbox-list.c"
You don't have a separate mail directory, so users sometimes list their entire home directory which can contain a huge directory tree, causing out of memory?
I wondered if anyone else has seen similar problems? It seems like once we fall into i_internal_fatal_handler(), dovecot should really try hard to avoid further dynamic memory allocation,
In other fatal handlers there was actually code to avoid infinitely recursing, but looks like I forgot to add it to internal_handler(). Fixed: http://hg.dovecot.org/dovecot-1.0/rev/c311c66a2d1b
Also v1.1+ sets aside an "out of memory" buffer which is used when logging the "out of memory" error.
as heap corruption seems to make that a bit of a disaster.
What heap corruption?
A final problem, and this one affects me personally, is that we see some errors like this:
dovecot: Jul 09 11:52:10 Error: IMAP(dp): FETCH for mailbox mail/tmp-inbox UID 92086 got too little data: 6054 vs 6057 dovecot: Jul 09 11:52:10 Info: IMAP(dp): Disconnected: Disconnected
This is frustrating because I wind up with "poisonous" messages in my inbox which cause dovecot to disconnect me when I try to read them. Across all of our users, we see this happen about 1000 times per month.
v1.1 fixes these automatically, although it still disconnects the first time. Deleting dovecot.index.cache fixes this of course.
But as for why it happens in the first place, that's a bit difficult to guess. Is the difference always 3 bytes? Anything else than Dovecot modifying the mboxes?