http://dovecot.org/test/ Just mbox fixes since 1.0-test16. The logic is simpler and more correct now. Can anyone break it anymore? I actually tested it a while with Evolution and several mailboxes and it didn't break at least immediately. :) Now maybe a few more days and I dare trying this thing myself with my real mboxes (yes, I'm still using them). Dovecot mailing list archives could soon be served with 1.0-tests too, as soon as I get support for read-only mboxes working again (storing and comparing MD5 summed headers). -------------- 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/20040618/956844c7/attachment-0001.bin>
Timo Sirainen wrote:> Just mbox fixes since 1.0-test16. The logic is simpler and more correct > now. Can anyone break it anymore?_o/, I can. Every time when indexes are rebuilt, new mail etc, Dovecot segfaults with this error in logs: Info: pop3-login: Login: joe [127.0.0.1] Error: POP3(joe): file mbox-sync.c: line 745 (mbox_sync_handle_eof_updates): assertion failed: (sync_ctx->expunged_space == 0) Error: child 21489 (pop3) killed with signal 6 Here's a backtrace of it. (gdb) bt #0 0x45dc0721 in kill () from /lib/libc.so.6 #1 0x45dc04c5 in raise () from /lib/libc.so.6 #2 0x45dc19e8 in abort () from /lib/libc.so.6 #3 0x0807de25 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:369 #4 0x0807d8f9 in i_panic (format=0x0) at failures.c:173 #5 0x0805f154 in mbox_sync_handle_eof_updates (sync_ctx=0x2e9, mail_ctx=0xba6eed80) at mbox-sync.c:813 #6 0x0805f8e1 in mbox_sync_update_imap_base (sync_ctx=0xba6eee50) at mbox-sync.c:952 #7 0x0805fc54 in mbox_sync (ibox=0x80a7eb8, last_commit=-1, lock=0) at mbox-sync.c:1053 #8 0x0805fdfb in mbox_storage_sync (box=0x80a7eb8, flags=0) at mbox-sync.c:1087 #9 0x08072746 in mailbox_sync (box=0x0, flags=1173120272) at mail-storage.c:372 #10 0x080674af in index_storage_get_status (box=0x80a7eb8, items=9, status=0xba6eefb0) at index-status.c:35 #11 0x0807271d in mailbox_get_status (box=0x45ec6510, items=0, status=0x0) at mail-storage.c:367 #12 0x08051d85 in init_mailbox (client=0x80a7a20) at client.c:54 #13 0x0805207c in client_create (hin=134780866, hout=0, storage=0x80a7930) at client.c:149 #14 0x08053723 in main_init () at main.c:119 #15 0x0805384c in main (argc=1, argv=0x0, envp=0x0) at main.c:152 (gdb) This system is a Debian GNU/Linux testing/unstable with kernel 2.4.26-grsec. -- Tomi Hakala
Hello Timo and list, I'm still getting some maildir errors with 1.0-test17: sp dovecot: IMAP(moe): file mail-transaction-log.c: line 1159 (mail_transaction_log_sync_lock): assertion failed: (!log->index->log_locked) sp dovecot: child 6497 (imap) killed with signal 6 It happens about once an hour, I'm not sure how it can be reliably reproduced, yet. regards On Fri, Jun 18, 2004 at 03:30:50AM +0300, Timo Sirainen wrote:> http://dovecot.org/test/ > > Just mbox fixes since 1.0-test16. The logic is simpler and more correct > now. Can anyone break it anymore? I actually tested it a while with > Evolution and several mailboxes and it didn't break at least > immediately. :) > > Now maybe a few more days and I dare trying this thing myself with my > real mboxes (yes, I'm still using them). > > Dovecot mailing list archives could soon be served with 1.0-tests too, > as soon as I get support for read-only mboxes working again (storing and > comparing MD5 summed headers).-- sed 's/mbox-support/shared-folders/g' <timo_todo.txt >timo_todo_new.txt #;)
Timo Sirainen wrote:> http://dovecot.org/test/ > > Just mbox fixes since 1.0-test16. The logic is simpler and more correct > now. Can anyone break it anymore? I actually tested it a while with > Evolution and several mailboxes and it didn't break at least > immediately. :)well I can break maildir here - although I'm quite unfair :-) I get a shitload of: Jun 18 22:39:58 cronos dovecot: IMAP(mm-mailinglist at madness.at): file mail-transaction-log-view.c: line 122 (mail_transaction_log_view_set): assertion failed: (min_file_seq != max_file_seq || min_file_offset <= max_file_offset) Jun 18 22:39:58 cronos dovecot: child 42945 (imap) killed with signal 6 Jun 18 22:39:58 cronos dovecot: imap-login: Login: mm-mailinglist at madness.at [195.70.118.73] Jun 18 22:39:58 cronos dovecot: IMAP(mm-mailinglist at madness.at): file mail-transaction-log-view.c: line 122 (mail_transaction_log_view_set): assertion failed: (min_file_seq != max_file_seq || min_file_offset <= max_file_offset) what I'm doing here is quite "strange" - though :-) i have courier-imap and dovecot serving the same(!) maildir (on different ports) for evaluation and comparison. what happens now is that new mail gets delivered into the inbox, mozilla-thunderbird (using the dovecot-connection) "sees" it and displays the headers, mozilla-thunderbird courier sees it too and "moves" the message into a subfolder due to a filterrule -> *booom*. while I agree that this is not a typical situation I would much prefer if dovecot could handle that a litte better then just crashing :-( OS is FreeBSD 4.10, client is mozilla-thunderbird. authentication is going through pgsql. Stefan