Still seeing a few core dumps via the deliver process and corrupted transaction log files with RC18:
Jan 22 10:46:36 zahara deliver(user@host.com): Corrupted transaction log file /data/mail/host.com/us/user@home.com/dovecot.index.log: start_offset (71680) > file size (71520) Jan 22 10:46:36 zahara deliver(user@host.com): seq = 6, rec->uid = 0, first_new_seq = 6, records = 5 Jan 22 10:46:36 zahara kernel: pid 41186 (deliver), uid 127: exited on signal 6 (core dumped)
Jan 22 10:50:17 zahara deliver(user@host.com): Corrupted transaction log file /data/mail/host.com/us/user@host.com/dovecot.index.log: Append with UID 512, but next_uid = 513
However, if the user gets another email, it appears deliver doesnt core dump again.
Thoughts?
-c
On Mon, 2007-01-22 at 10:54 -0700, Cassidy B. Larson wrote:
Jan 22 10:46:36 zahara deliver(user@host.com): Corrupted transaction log file /data/mail/host.com/us/user@ home.com/dovecot.index.log: start_offset (71680) > file size (71520)
Dean, do you see this before the below error too?
Jan 22 10:46:36 zahara deliver(user@host.com): seq = 6, rec->uid = 0, first_new_seq = 6, records = 5
Is it only deliver that crashes with this error, or does imap too?
The easiest way for me to debug this would be if I could examine the core file myself with gdb. If the core file doesn't contain anything too secret (you could check with eg. strings), could you send me the core file and the deliver binary that produced it?
Although I don't know how well gdb handles other OSes binaries. I can at least debug Linux/x86/x86_64 and Solaris/Sparc binaries.
If I can't directly check the core file's contents, I'll try adding more asserts to catch this bug earlier so I could figure out what's causing it..
participants (2)
-
Cassidy B. Larson
-
Timo Sirainen