On Thu, 2006-11-23 at 16:09 +0100, Hans Morten Kind wrote:
12:27:00 [local3.error] IMAP(USER): Corrupted index cache file imapindex/USER/.imap/INBOX/dovecot.index.cache: invalid field header size 12:28:23 [local3.error] IMAP(USER): mremap_anon(1164206080) failed: Not enough space
Hmh. I don't really get how this is possible. Or do you use 32bit file offsets instead of the 64bit (which should be default)? Running configure outputs that at least.
I added anyway a couple of extra checks, but with 64bit file offsets these shouldn't happen, since only 32bit offsets are ever passed to the functions:
http://dovecot.org/list/dovecot-cvs/2006-December/006995.html
And BTW. the mail process sizes are by default limited to 256MB virtual memory, so that's why it gave "not enough space" error. Except it should have given ENOMEM, not ENOSPC, but that's probably some Solaris thing.
The messages from 'mremap_anon' have never been seen before. Actually '1164206080' looks very much like a timestamp, differing 75223 seconds from the time of the crash ... spooky
Yes, it is..
I will start running the supplied code for memory debugging on this user and I enclose a back trace from the crash.
I don't think it will help. Probably something in the cache file is treated as a file offset/size and somehow in a way I can't see right now it gets passed to file_cache_read().
As for why broken cache files are seen, I guess you're using NFS and multiple machines can access the same user's mailbox? So some cache inconsistency problems probably..
The interessting stuff from the back trace is probably that hdr (and so cache->hdr) is 0xffffffff so that hdr->continued_record_count gives no sense (Cannot access memory at address 0xb) but cache->index->map->records_count is 320
This is fixed now:
http://dovecot.org/list/dovecot-cvs/2006-December/006998.html