Mark Zealey
2008-Jul-03 09:12 UTC
[Dovecot] assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
Hi guys, Anyone know what this error with deliver is (v1.1.1)? 2008-07-03T09:45:19+01:00 mail4 deliver(alexander): Panic: file mail-index-transaction.c: line 642 (mail_index_transaction_lookup): assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq) Seen a few of these this morning. Mark -- Mark Zealey -- Shared Hosting Team Leader Product Development * Webfusion 123-reg.co.uk, webfusion.co.uk, donhost.co.uk, supanames.co.uk This mail is subject to http://www.gxn.net/disclaimer
Timo Sirainen
2008-Jul-03 09:21 UTC
[Dovecot] assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
On Jul 3, 2008, at 2:42 PM, Mark Zealey wrote:> Hi guys, > > Anyone know what this error with deliver is (v1.1.1)? > > 2008-07-03T09:45:19+01:00 mail4 deliver(alexander): Panic: file > mail-index-transaction.c: line 642 (mail_index_transaction_lookup): > assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)Could you get gdb backtrace from this? Although depending on your configuration it might be tricky to get core dumps.. http://dovecot.org/bugreport.html has some ideas, but it doesn't really talk about deliver. I guess the main things are: - user should have a writable home directory (where the core is written to) - run ulimit -c unlimited before running your MTA -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080703/918fd2c1/attachment-0002.bin>
Mark Zealey
2008-Jul-03 14:42 UTC
[Dovecot] assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
OK I've been struggling to get dumps from the live environment most of the day, but have given up. I've now managed to reproduce this using a fork-bomb type script; here is a backtrace (no debug version installed, but I suspect I could reproduce this in the dev environment if it's not clear what the error is). (gdb) bt #0 0x004ef402 in __kernel_vsyscall () #1 0x00138c00 in raise () from /lib/libc.so.6 #2 0x0013a451 in abort () from /lib/libc.so.6 #3 0x080c413d in default_error_handler () #4 0x080c41cd in i_syslog_fatal_handler () #5 0x080c3a2c in i_panic () #6 0x080a072c in mail_index_transaction_lookup () #7 0x080a39d7 in mail_index_transaction_open_updated_view () #8 0x080b2853 in mail_cache_decision_add () #9 0x0809b884 in mail_cache_add () #10 0x08089910 in index_mail_cache_add_idx () #11 0x08089a03 in index_mail_cache_add () #12 0x08089ec7 in index_mail_close () #13 0x0808ad90 in index_mail_free () #14 0x08092f42 in mail_free () #15 0x0806c63c in maildir_transaction_save_commit_pre () #16 0x08065d62 in maildir_transaction_class_deinit () #17 0x08092cce in index_transaction_commit () #18 0x08094a56 in mailbox_transaction_commit () #19 0x0805a416 in deliver_save () #20 0x0805b99a in main () The way I caused this crash was: [root at mail2 tmp]# cat t.sh #!/bin/bash HOME=/path/to/nfs/Maildir/ export HOME exec /usr/libexec/dovecot/deliver -f foo at bar.com Then in bash as root: # i=0; while true; do echo $i; i=$((i+1)); sudo -u exim /tmp/t.sh < /root/t & sudo -u exim /tmp/t.sh < /root/t & sudo -u exim /tmp/t.sh < /root/t & sudo -u exim /tmp/t.sh < /root/t & sudo -u exim /tmp/t.sh < /root/t & sudo -u exim /tmp/t.sh < /root/t & done After about 3 seconds I got 10 crashes and core dumps. A word about our setup; we have the maildirs stored on an nfs mount and deliver could be called on multiple heads at the same time for deliveries - I suspect this is what was causing the problem. Our nfs mount options are rw,noatime,nodiratime,hard,intr,rsize=32768,wsize=32768,tcp,nocto. Running centos 5.1 on the boxes with exim. Thanks, Mark