dovecot - Jul 2008 - 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

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>

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