[dovecot] pop3 coredump
Hi-
I was able to get a coredump out of the new pop3 (from 0.99.9-test4) by attempting to simulate the execution environment and simply running the pop3 program.
Running the older pop3 from 0.99.8.1 works fine, repeatedly:
% /usr/local/libexec/dovecot/pop3 quit +OK Logging out.
However running the new one:
% /usr/local/libexec/dovecot/pop3.new pop3(user9): Error: Corrupted index file /users/48/user9/Maildir/.INBOX/.imap.index: index.next_uid (4539) > uidlist.next_uid (4000) Segmentation fault (core dumped)
It doesn't always dump core even with this message. The error message is not always the same, but it's usually what's above. Simply repeating the invocation a number of times I also saw:
pop3(user9): Error: Corrupted index file (in-memory index for /users/48/user9/Maildir): Filename mismatch for UID 1: 1050440153.17005.mercury.mv.net vs 1050437948.5418.mercury.mv.net
Here's some gdb output corresponding to the coredump above.
-mm-
Script started on Tue Apr 15 16:51:28 2003
% gdb pop3/pop3 pop3.core
...
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libiconv.so.2...done.
Reading symbols from /shlib/libgcc.so.1...done.
Reading symbols from /shlib/libc.so.2...done.
Reading symbols from /shlib/ld-bsdi.so...done.
#0 0x0 in ?? ()
(gdb) bt
#0 0x0 in ?? ()
#1 0x8053439 in index_storage_init (storage=0x808f000, box=0x8080658,
index=0x808c200, name=0x807660e "INBOX", readonly=0, fast=0)
at index-storage.c:264
#2 0x804b8e0 in maildir_open (storage=0x808f000, name=0x807660e "INBOX",
readonly=0, fast=0) at maildir-storage.c:239
#3 0x804ba20 in maildir_open_mailbox (storage=0x808f000,
name=0x80765b1 "INBOX", readonly=0, fast=0) at maildir-storage.c:288
#4 0x804b1c7 in main_init () at main.c:98
#5 0x804b269 in main (argc=1, argv=0x8047d3c, envp=0x8047d44) at main.c:132
#6 0x8049cae in __start ()
(gdb) up 1
#1 0x8053439 in index_storage_init (storage=0x808f000, box=0x8080658,
index=0x808c200, name=0x807660e "INBOX", readonly=0, fast=0)
at index-storage.c:264
264 storage->callbacks->notify_no(&ibox->box,
(gdb) l
259 if (!index->open(index, flags))
260 break;
261
262 if (INDEX_IS_IN_MEMORY(index) &&
263 storage->index_dir != NULL) {
264 storage->callbacks->notify_no(&ibox->box,
265 "Couldn't use index files",
266 storage->callback_context);
267 }
268 }
(gdb) p index
$1 = (struct mail_index *) 0x808c200
(gdb) p *index
$2 = {open = 0x8054590
On Wed, 2003-04-16 at 00:07, Mark E. Mallett wrote:
% /usr/local/libexec/dovecot/pop3.new pop3(user9): Error: Corrupted index file /users/48/user9/Maildir/.INBOX/.imap.index: index.next_uid (4539) > uidlist.next_uid (4000)
What if you delete the dovecot-uidlist file? Or the index files? Does it still do this?
#0 0x0 in ?? () #1 0x8053439 in index_storage_init (storage=0x808f000, box=0x8080658, index=0x808c200, name=0x807660e "INBOX", readonly=0, fast=0) at index-storage.c:264
Thanks, this helps to fix the crash. It doesn't explain the "corrupted index file" messages though, except that they never get fixed because of this.
On Wed, Apr 16, 2003 at 02:17:20AM +0300, Timo Sirainen wrote:
On Wed, 2003-04-16 at 00:07, Mark E. Mallett wrote:
% /usr/local/libexec/dovecot/pop3.new pop3(user9): Error: Corrupted index file /users/48/user9/Maildir/.INBOX/.imap.index: index.next_uid (4539) > uidlist.next_uid (4000)
What if you delete the dovecot-uidlist file? Or the index files? Does it still do this?
If I rename dovecot-uidlist out of the way, it successfully builds a new one and no longer complains, and is happy on repeated invocations. If I put back the dovecot-uidlist, it is not happy again.
However- the same is true of the .imap* files. If I move them out of the way (and leave the old dovecot-uidlist in place), the new pop3 is happy to build a new set and use them (again, on repeated invocations). If I move back the old .imap* files, the error is back.
So- moving either of those helps. The older pop3 also seems happy to use the newly generated files. (but again it's also happy with the old ones).
I don't know what happens if new mail comes in after the new files are generated.
mm
On Wed, 2003-04-16 at 02:35, Mark E. Mallett wrote:
If I rename dovecot-uidlist out of the way, it successfully builds a new one and no longer complains, and is happy on repeated invocations. If I put back the dovecot-uidlist, it is not happy again.
However- the same is true of the .imap* files. If I move them out of the way (and leave the old dovecot-uidlist in place), the new pop3 is happy to build a new set and use them (again, on repeated invocations). If I move back the old .imap* files, the error is back.
So- moving either of those helps.
OK, I think the problem is then just that Dovecot crashes before it has time to rebuild index file. And it's broken because previous -test releases broke it.
The older pop3 also seems happy to use the newly generated files. (but again it's also happy with the old ones).
That's because older versions didn't use the uidlist file at all.
I don't know what happens if new mail comes in after the new files are generated.
Probably works.
participants (2)
-
Mark E. Mallett
-
Timo Sirainen