[Dovecot] 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.
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...
participants (2)
-
Timo Sirainen
-
Todd Burroughs