On Thu, 14 Oct 2004, Timo Sirainen wrote:
On 14.10.2004, at 00:37, dovecot@spam.turbolink.net wrote:
I moved to test47 which seems to fix several crashes, (including one problem with messages that have no body text) but causes a couple of new problems, one with POP3. Here is a diff between the actual mailbox and what dovecot returns through POP3:
313c308,309 < mv7g4W3sBDM8+I/ fLuH7LqwrqxcKOgcjB2Lp7Uqc9AQle3Z5elK9PK1WCSFWX7eVRTKPmlmP
mv7g4W3sBDM8+I/ fLuH7LqwrqxcKOgcjB2Lp7Uqc9AQle3Z5elK9PK1WCSFWX7eVRTKPmlmPPYmplY3QgL1N1 YnR5cGUgL0lt YWdlIC9XaWR0aCA2NSAvS
The extra data "PPYmplY3QgL1N1YnR5cGUgL0lt" doesn't appear anywhere in the mbox, I'm not sure where it's coming from.?? Pulling the same message through with IMAP seems to be no problem...
Can you reproduce this easily? What about after removing indexes?
Yes I can, I've setup test47 on a test machine with a mailbox that exhibits this problem. The problem occurs even if I trash the indexes. If I disconnect and reconnect I get corruption at a different offset and with different data.
Here's another new one. I see it trying to allocate 1075105600 bytes but it's not clear to me why:
This might be fixed in CVS now. I'll release test48 tomorrow if nothing seems to be broken.
And still seeing this one:
POP3(mkuker): file mbox-lock.c: line 493 (mbox_lock): assertion failed: (lock_type == F_RDLCK || ibox->mbox_lock_type != F_RDLCK)
I haven't looked this much yet.. Although it might have gotten fixed after I did lots of changes to how pop3 works internally.
Ok. Will pull test48 and retest.
- Mike