dovecot - Mar 2005 - Segfault in imap process

We've been testing dovecot for a while and I noticed yesterday that imap
crashes quite often.  It seems to be about even with SIGABRT and SIGSEGV.
This one was SIGSEGV.

Our system is SuSE Linux 9.2, 2.6.11.5 kernel (also happened with an older
2.6 kernel).  Dovecot version is 1.0-test64 and was compiled with:
"./configure --prefix=/services/dovecot --disable-ipv6"

It's using mbox over NFS and I've configured "mmap_disable =
yes".

The mailbox that it crashed on is one of our support mailboxes and it
is pretty busy.  In the last 1/2 hour, it received over 100 emails.

I had a look at the code, but didn't notice anything obvious.  Thanks
for any help...


Here's the log messages:
dovecot: Mar 22 18:22:23 Error:  19697 IMAP(support): UIDVALIDITY changed
(1111532787 -> 1111533642) in mbox file /mailhome/new/s/support/mbox
dovecot: Mar 22 18:22:26 Error: child 19697 (imap) killed with signal 11


and a backtrace:

mail201:/services/dovecot/var/log # gdb /services/dovecot/libexec/dovecot/imap
imap.core.pid19697
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.

warning: current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x08079f14 in mail_cache_sync_lost_handler (index=0x0)
     at mail-cache-sync-update.c:152
152             file_cache_invalidate(index->cache->file_cache, 0,
(uoff_t)-1);
(gdb) bt
#0  0x08079f14 in mail_cache_sync_lost_handler (index=0x0)
     at mail-cache-sync-update.c:152
#1  0x0807bcfb in mail_index_map (index=0x80c24e8, force=0) at mail-index.c:792
#2  0x0807c870 in mail_index_try_open (index=0x80c24e8, lock_id_r=0xbffff68c)
     at mail-index.c:1064
#3  0x0807c9cf in mail_index_open (index=0x80c24e8, flags=5,
     lock_method=MAIL_INDEX_LOCK_FCNTL) at mail-index.c:1219
#4  0x08076025 in index_storage_mailbox_init (storage=0x80b7b90,
     box=0x80ac920, index=0x80c24e8, name=0x80a292f "INBOX",
flags=Variable "flags" is not available.
)
     at index-storage.c:330
#5  0x08067cd8 in mbox_open (storage=0x80b7b90, name=0x80a292f
"INBOX",
     flags=0) at mbox-storage.c:510
#6  0x08067ea4 in mbox_mailbox_open (_storage=0x80b7b90,
     name=0x80a292f "INBOX", flags=0) at mbox-storage.c:557
#7  0x08089305 in mailbox_open (storage=0x0, name=0x80a292f "INBOX",
flags=0)
     at mail-storage.c:292
#8  0x08057ace in _cmd_select_full (cmd=0x80b7e80, readonly=0)
     at cmd-select.c:32
#9  0x08057ca1 in cmd_select (cmd=0x80b7e80) at cmd-select.c:99
#10 0x08059145 in _client_input (context=0x80b7e40) at client.c:334
#11 0x08099eca in io_loop_handler_run (ioloop=0x80b69e8) at ioloop-poll.c:184
#12 0x080995e9 in io_loop_run (ioloop=0x80b69e8) at ioloop.c:218
#13 0x0805fea7 in main (argc=1, argv=0xbffffa24, envp=0xbffffa2c) at main.c:229
(gdb)


Todd Burroughs

On Tue, 2005-03-22 at 19:12 -0500, Todd Burroughs wrote:
> It's using mbox over NFS and I've configured "mmap_disable =
yes".
> 
> The mailbox that it crashed on is one of our support mailboxes and it
> is pretty busy.  In the last 1/2 hour, it received over 100 emails.
> 
> I had a look at the code, but didn't notice anything obvious.  Thanks
> for any help...
> 
> 
> Here's the log messages:
> dovecot: Mar 22 18:22:23 Error:  19697 IMAP(support): UIDVALIDITY changed
(1111532787 -> 1111533642) in mbox file /mailhome/new/s/support/mbox
This is your primary problem. Why is it changing? It sounds like
Dovecot's index files aren't in NFS, and you're accessing the mbox
from
multiple computers with different index files?

That alone doesn't break it, but if the first message is expunged with
non-Dovecot/c-client software, the UIDVALIDITY is lost and Dovecot
creates a new one. But another Dovecot instance with existing index
files tries to use the old UIDVALIDITY and so it complains about the
change.

Is something else than Dovecot expunging the messages, or
deleting/truncating the mbox entirely?
> #0  0x08079f14 in mail_cache_sync_lost_handler (index=0x0)
>      at mail-cache-sync-update.c:152
> 152             file_cache_invalidate(index->cache->file_cache, 0,
(uoff_t)-1);
Thanks, fixed in CVS.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20050325/2bd3bef8/attachment-0001.bin>

On Fri, 25 Mar 2005, Timo Sirainen wrote:
> On Tue, 2005-03-22 at 19:12 -0500, Todd Burroughs wrote:
>> It's using mbox over NFS and I've configured "mmap_disable
= yes".
>>
>> Here's the log messages:
>> dovecot: Mar 22 18:22:23 Error:  19697 IMAP(support): UIDVALIDITY
changed (1111532787 -> 1111533642) in mbox file /mailhome/new/s/support/mbox
>
> This is your primary problem. Why is it changing? It sounds like
> Dovecot's index files aren't in NFS, and you're accessing the
mbox from
> multiple computers with different index files?
The indexes are on NFS and they are being accessed from the same server.
It is quite possible that several people are trying to access this
mailbox at once.  It should be one person at a time, but I'm sure that
they occasionally do this.
> That alone doesn't break it, but if the first message is expunged with
> non-Dovecot/c-client software, the UIDVALIDITY is lost and Dovecot
> creates a new one. But another Dovecot instance with existing index
> files tries to use the old UIDVALIDITY and so it complains about the
> change.
>
> Is something else than Dovecot expunging the messages, or
> deleting/truncating the mbox entirely?
They are mostly using Dovecot, but some are likely using UW IMAP.

I do have these settings, maybe a mistake: 
mbox_very_dirty_syncs = yes
mbox_lazy_writes = yes
> Thanks, fixed in CVS.
Thanks, I'll test it now...