On Fri, 2007-01-12 at 17:08 +0100, Cor Bosman wrote:
Dec 10 18:55:44 dovecot2.xs4all.nl dovecot: IMAP(XXX): Corrupted
Index file /var/run/dovecot-index/l/ld/XXX/.INBOX/dovecot.index:
Record [27].uid=0Have you tried yet if rc17 fixes these?
Hi Timo, as I said before, they're not fixed.
I found two more view syncing bugs: http://dovecot.org/list/dovecot-cvs/2007-January/007366.html http://dovecot.org/list/dovecot-cvs/2007-January/007368.html
Maybe those would help?
I dont get coredumps anymore which makes this very hard for me to debug.
You mean Dovecot just doesn't do that, or you did it on purpose for some reason? You should get core dumps as long as:
- you have a home directory set and user can write there
- mail_drop_priv_before_exec=yes
- ulimit -c was high enough before dovecot was started
As we noticed before, the index files seem fine (you checked that). Would it be possible to make a patch that doesnt copy the files, but dumps the in-memory index someplace?
Yea, I could do that if the above patches don't help. Although the easiest way to debug this would be looking into the core file with gdb..
It must be something very unlikely, as I see this on a tiny fraction of our connections. Something like 1 in every 100000. Could it be some race condition on the lock file, and a second process reads a partial index?
Some of the reasons that I can think of are:
messages_count is too high in the header. I suppose this could have happened because of locking problems, if index gets read after the file header is updated, but before the message record is updated.
something to do with appending/copying messages. newly appended messages have uid=0 temporarily in memory.
the memory area is completely broken and is filled with zeroes.
Hmm. I'm beginning to think that 1. might be the most likely problem. Have you tried changing lock_method? Try switching to flock (or to fcntl).