[Dovecot] 1.0.alpha4 released
The actual alpha4 release this time. With a few changes since the pre-release.
The important changes again:
Default lock_method changed to flock instead of the old fcntl. Solaris users will need to set it back to fcntl. This makes sure that Dovecot's indexes aren't accidentally used with NFS.
IMAP: We might have sent extra EXPUNGE messages when output buffer got full. This could have caused various sorts of very bad behavior. This is the main reason why everyone should upgrade as soon as possible.
POP3: We sent duplicate replies for LIST command when output buffer got full. Probably caused Thunderbird's duplicate deletion bugs? (Although I thought someone checked that Dovecot's reply was correct when the bug occurred?)
pop3_uidl_format setting is now required to be explicitly set in configuration file for pop3 to work at all. I want to get rid of the old default setting which breaks Outlooks, and simply changing the default would break existing setups.
Multiple passdbs and userdbs of same type can now be added with different parameters. Some people asked about this earlier.
Authentication cache works now with other than SQL and LDAP passdbs. Some passdbs such as PAM require some additional settings to work. See example config file.
Some other fixes to authentication cache related to failure handling and non-plaintext authentication.
deny passdb wasn't working for non-plaintext authentication.
New changes since alpha4 pre-release:
- imap/pop3 proxy feature was broken
- fixed an assert-crash in ostream-file.c that was only in the pre-release
And some more changes since alpha3 that I didn't mention before:
- zlib plugin updated in http://dovecot.org/patches/1.0/zlib-plugin.tar.gz to be much faster than before
- Added ssl_username_from_cert setting. Not actually tested yet, does it work?
- epoll was broken with 64bit systems
- Added deny password databases.
- Dovecot can be run from inetd again
- Index breakage/crashfix related to adding new keywords
And what does zlib-plugin do ?
Regads, Sebastjan
On 20/10/05, Timo Sirainen tss@iki.fi wrote:
The actual alpha4 release this time. With a few changes since the pre-release.
The important changes again:
Default lock_method changed to flock instead of the old fcntl. Solaris users will need to set it back to fcntl. This makes sure that Dovecot's indexes aren't accidentally used with NFS.
IMAP: We might have sent extra EXPUNGE messages when output buffer got full. This could have caused various sorts of very bad behavior. This is the main reason why everyone should upgrade as soon as possible.
POP3: We sent duplicate replies for LIST command when output buffer got full. Probably caused Thunderbird's duplicate deletion bugs? (Although I thought someone checked that Dovecot's reply was correct when the bug occurred?)
pop3_uidl_format setting is now required to be explicitly set in configuration file for pop3 to work at all. I want to get rid of the old default setting which breaks Outlooks, and simply changing the default would break existing setups.
Multiple passdbs and userdbs of same type can now be added with different parameters. Some people asked about this earlier.
Authentication cache works now with other than SQL and LDAP passdbs. Some passdbs such as PAM require some additional settings to work. See example config file.
Some other fixes to authentication cache related to failure handling and non-plaintext authentication.
deny passdb wasn't working for non-plaintext authentication.
New changes since alpha4 pre-release:
- imap/pop3 proxy feature was broken
- fixed an assert-crash in ostream-file.c that was only in the pre-release
And some more changes since alpha3 that I didn't mention before:
- zlib plugin updated in http://dovecot.org/patches/1.0/zlib-plugin.tar.gz to be much faster than before
- Added ssl_username_from_cert setting. Not actually tested yet, does it work?
- epoll was broken with 64bit systems
- Added deny password databases.
- Dovecot can be run from inetd again
- Index breakage/crashfix related to adding new keywords
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBDV2s6yUhSUUBViskRAoHFAJ9jdPbl9YWZjDLnLzumhdN28tLr+wCgilzG OROLeLoAT51OYxmGmglPjZ4= =JAeG -----END PGP SIGNATURE-----
Timo Sirainen wrote:
The actual alpha4 release this time. With a few changes since the pre-release.
Hi,
I've just upgraded dovecot from alpha3 to alpha4 and after the upgrade I've experienced errors like:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(ext->name)) == 0)
file mail-index-sync-ext.c: line 336 (sync_ext_resize): assertion failed: (ext[i].hdr_offset > ext[i-1].hdr_offset)
file mail-index-transaction.c: line 831 (mail_index_update_ext): assertion failed: (seq > 0 && (seq <= mail_index_view_get_messages_count(t->view) || seq <= t->last_new_seq))
file mbox-sync-rewrite.c: line 375 (mbox_sync_read_and_move): assertion failed: (need_space == (uoff_t)-mails[idx].space)
file mbox-sync.c: line 1295 (mbox_sync_handle_eof_updates): assertion failed: (file_size >= sync_ctx->expunged_space + trailer_size)
I can remember errors like this previously using 0.99 version of dovecot, but when using alpha3 they were gone. Any reason I get this again now?
Some short information regarding my setup:
- Debian Stable 3.1
- Dovecot compiled from source
- Using mbox (or maildir for some users, but not for the users I experience errors)
- Anders
Anders Lund wrote:
I've just upgraded dovecot from alpha3 to alpha4 and after the upgrade I've experienced errors like:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(ext->name)) == 0)
Are these from IMAP processes?
Could you do "egrep -e "lock|mbox|mmap" dovecot.conf" and mail the output to list?
Is your mail spool or indexes on a NFS mount?
Are you using Dovecot LDA?
Anyway, to help Timo to solve the problem please try to produce backtraces from cores you are hopefully getting on crashes.
http://dovecot.org/bugreport.html
-- Tomi Hakala
Tomi Hakala wrote:
Anders Lund wrote:
I've just upgraded dovecot from alpha3 to alpha4 and after the upgrade I've experienced errors like:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(ext->name)) == 0)
Are these from IMAP processes?
Yes.
Could you do "egrep -e "lock|mbox|mmap" dovecot.conf" and mail the output to list?
Guess you're not interested in the commented lines, so:
lock_method = fcntl mbox_read_locks = fcntl dotlock mbox_write_locks = fcntl dotlock
Is your mail spool or indexes on a NFS mount?
No kind of NFS mounting on this host.
Are you using Dovecot LDA?
No.
Anyway, to help Timo to solve the problem please try to produce backtraces from cores you are hopefully getting on crashes.
I've not had any crash yet.
- Anders
Anders Lund wrote:
lock_method = fcntl mbox_read_locks = fcntl dotlock mbox_write_locks = fcntl dotlock
Could you try to see if switching to flock would make any difference? Just remember to make sure your MTA/LDA uses at least dotlocking if you cannot switch it to use flock.
I'm personally using only flock and I haven't seen any problems with Dovecot 1.0.alpha4.
Are you using Dovecot LDA?
No.
Since you are using mbox you would gain a lot from using Dovecot LDA, I'v been using it a several months now.
I've not had any crash yet.
Assertion failures are crashes, you should get core file from each of those if your system is configured to create core files, you also need "mail_drop_priv_before_exec = yes" in dovecot.conf.
-- Tomi Hakala
Tomi Hakala wrote:
Anders Lund wrote:
lock_method = fcntl mbox_read_locks = fcntl dotlock mbox_write_locks = fcntl dotlock
Could you try to see if switching to flock would make any difference? Just remember to make sure your MTA/LDA uses at least dotlocking if you cannot switch it to use flock.
I'm personally using only flock and I haven't seen any problems with Dovecot 1.0.alpha4.
Only for "lock_method", or the other two lock methods as well?
I use Postfix and have set:
mailbox_delivery_lock = fcntl, dotlock
Are you using Dovecot LDA?
No.
Since you are using mbox you would gain a lot from using Dovecot LDA, I'v been using it a several months now.
I'm not sure I understand. Why would I gain a lot from using Dovecot LDA? Typically users could use Procmail for filtering, and deliver to their different mboxes. I might be interested in looking at Dovecot LDA because of SIEVE, but can't see how using it will give me any big advantages. On the other hand I haven't looked too much at it, so I guess I should have a closer look at the doc/wiki. ;-)
I've not had any crash yet.
Assertion failures are crashes, you should get core file from each of those if your system is configured to create core files, you also need "mail_drop_priv_before_exec = yes" in dovecot.conf.
OK. I'll add "mail_drop_priv_before_exec" and see if I get any core files.
Thanks for the suggestions Tomi.
Kippis!
- Anders
Anders Lund wrote:
Tomi Hakala wrote: [...]
Assertion failures are crashes, you should get core file from each of those if your system is configured to create core files, you also need "mail_drop_priv_before_exec = yes" in dovecot.conf.
OK. I'll add "mail_drop_priv_before_exec" and see if I get any core files.
I've had more failures like:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(e xt->name)) == 0)
(logged for "imap"), but I'm unable to find any core-files even though I've added "mail_drop_priv_before_exec"... Where should I find these core dumps?
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
core files appear in the home directory or whereever the index files and mailbox folders for a user go. At least with imap.
Jeff Earickson Colby College
On Mon, 24 Oct 2005, Anders Lund wrote:
Date: Mon, 24 Oct 2005 12:33:10 +0200 From: Anders Lund anders.lund@uninett.no To: Tomi Hakala tomi.hakala@clinet.fi Cc: dovecot@dovecot.org Subject: Re: [Dovecot] 1.0.alpha4 released
Anders Lund wrote:
Tomi Hakala wrote: [...]
Assertion failures are crashes, you should get core file from each of those if your system is configured to create core files, you also need "mail_drop_priv_before_exec = yes" in dovecot.conf.
OK. I'll add "mail_drop_priv_before_exec" and see if I get any core files.
I've had more failures like:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(e xt->name)) == 0)
(logged for "imap"), but I'm unable to find any core-files even though I've added "mail_drop_priv_before_exec"... Where should I find these core dumps?
- Anders
-- Anders Lund Anders.Lund@uninett.no .~. UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Jeff A. Earickson wrote:
core files appear in the home directory or whereever the index files and mailbox folders for a user go. At least with imap.
Ok. I'm unable to find any core-files in this location as well.
- Anders
Anders Lund wrote:
Tomi Hakala wrote:
[...]
Assertion failures are crashes, you should get core file from each of those if your system is configured to create core files, you also need "mail_drop_priv_before_exec = yes" in dovecot.conf.
OK. I'll add "mail_drop_priv_before_exec" and see if I get any core files.
I've had more failures like:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(e xt->name)) == 0)
(logged for "imap"), but I'm unable to find any core-files even though I've added "mail_drop_priv_before_exec"... Where should I find these core dumps?
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
On Mon, 24 Oct 2005, Anders Lund wrote:
Jeff A. Earickson wrote:
core files appear in the home directory or whereever the index files and mailbox folders for a user go. At least with imap.
Ok. I'm unable to find any core-files in this location as well.
You may need to set the ulimit for core files, it quite often defaults to 0. Try starting dovecot something like this:
ulimit -c unlimited ; dovecot
Todd
Hi, While I subscribe to the idea that "well written code never core dumps", I *want* core dumps in this case -- so I can run them thru gdb and help improve the code. I just don't want a zillion of the same assert, which wasn't there in alpha3.
Jeff
On Mon, 24 Oct 2005, Todd Burroughs wrote:
Date: Mon, 24 Oct 2005 17:47:44 -0400 (EDT) From: Todd Burroughs todd@hostopia.com To: Anders Lund anders.lund@uninett.no Cc: dovecot@dovecot.org Subject: Re: [Dovecot] 1.0.alpha4 released
On Mon, 24 Oct 2005, Anders Lund wrote:
Jeff A. Earickson wrote:
core files appear in the home directory or whereever the index files and mailbox folders for a user go. At least with imap.
Ok. I'm unable to find any core-files in this location as well.
You may need to set the ulimit for core files, it quite often defaults to 0. Try starting dovecot something like this:
ulimit -c unlimited ; dovecot
Todd
Todd Burroughs wrote:
You may need to set the ulimit for core files, it quite often defaults to 0. Try starting dovecot something like this:
ulimit -c unlimited ; dovecot
Tnx, Todd. Worked. I've now got a core file. (I should have found out about "ulimit" from www.dovecot.org before. Sorry about that...)
I'm not an expert on using gdb. What I get from running gdb on the core-file is:
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6
Is this enough information to get some expert's comments on this? ;-)
The core was a result from this assertion:
file mbox-sync.c: line 1332 (mbox_sync_update_index_header): assertion failed: (sync_ctx->base_uid_validity != 0 || st->st_size == 0)
I've had other asserions before (as I've posted on the list), but not after I've enabled core-dumps. I could post similar results from gdb if I experience more of this, with other assertions...
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
On Tue, 2005-10-25 at 14:40 +0200, Anders Lund wrote:
I'm not an expert on using gdb. What I get from running gdb on the core-file is:
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6
Is this enough information to get some expert's comments on this? ;-)
No :) Enter 'bt full' or 'bt' in gdb, and paste what that outputs (please turn off line wrapping)
johannes
Johannes Berg wrote:
Enter 'bt full' or 'bt' in gdb, and paste what that outputs (please turn off line wrapping)
Learning, step by step... :)
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6 #1 0xb7ed5fa2 in abort () from /lib/tls/libc.so.6 #2 0x080a26d5 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:375 #3 0x080a2169 in i_panic (format=0x0) at failures.c:173 #4 0x0807366a in mbox_sync_update_index_header (sync_ctx=0xbffff910) at mbox-sync.c:1361 #5 0x0807388d in mbox_sync_do (sync_ctx=0xbffff910, flags=MBOX_SYNC_UNDIRTY) at mbox-sync.c:1474 #6 0x08073efc in mbox_sync (mbox=0x80d09e8, flags=MBOX_SYNC_UNDIRTY) at mbox-sync.c:1692 #7 0x08074374 in mbox_storage_sync_init (box=0x80d09e8, flags=MAILBOX_SYNC_FLAG_FULL_READ) at mbox-sync.c:1770 #8 0x08095a46 in mailbox_sync_init (box=0x0, flags=6) at mail-storage.c:336 #9 0x0805fe4d in imap_sync_nonselected (box=0x0, flags=0) at imap-sync.c:177 #10 0x0805810f in _cmd_select_full (cmd=0x80ca9f0, readonly=0) at cmd-select.c:39 #11 0x080582c7 in cmd_select (cmd=0x0) at cmd-select.c:92 #12 0x08059b3a in client_handle_input (cmd=0x80ca9f0) at client.c:338 #13 0x08059c5d in _client_input (context=0x80ca9b0) at client.c:390 #14 0x080a8658 in io_loop_handler_run (ioloop=0x80c99b0) at ioloop-poll.c:190 #15 0x080a7a98 in io_loop_run (ioloop=0x80c99b0) at ioloop.c:230 #16 0x08061bc9 in main (argc=1, argv=0x0, envp=0x0) at main.c:232
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
I've got another assertion failed with dovecot 1.0 alpha4 (compiled on Debian Stable 3.1):
file mail-index-transaction.c: line 831 (mail_index_update_ext): assertion failed: (seq > 0 && (seq <= mail_index_view_get_messages_count(t->view) || seq <= t->last_new_seq))
Result from running gdb on the core file:
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6 #1 0xb7ed5fa2 in abort () from /lib/tls/libc.so.6 #2 0x080a26d5 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:375 #3 0x080a2169 in i_panic (format=0x0) at failures.c:173 #4 0x08088a2e in mail_index_update_ext (t=0xb7fdde80, seq=1, ext_id=2, data=0x6, old_data_r=0x0) at mail-index-transaction.c:829 #5 0x08071f17 in update_from_offsets (sync_ctx=0xbfffe1a0) at mbox-sync.c:661 #6 0x080731ec in mbox_sync_handle_eof_updates (sync_ctx=0xbfffe1a0, mail_ctx=0xbfffe0a0) at mbox-sync.c:1271 #7 0x08073855 in mbox_sync_do (sync_ctx=0xbfffe1a0, flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1465 #8 0x08073efc in mbox_sync (mbox=0x80db020, flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1692 #9 0x0806c4d6 in mbox_storage_close (box=0x80db020) at mbox-storage.c:973 #10 0x0809598f in mailbox_close (box=0x0) at mail-storage.c:303 #11 0x08055bdb in cmd_close (cmd=0x80ca9f0) at cmd-close.c:24 #12 0x08059b3a in client_handle_input (cmd=0x80ca9f0) at client.c:338 #13 0x08059c5d in _client_input (context=0x80ca9b0) at client.c:390 #14 0x080a8658 in io_loop_handler_run (ioloop=0x80c99b0) at ioloop-poll.c:190 #15 0x080a7a98 in io_loop_run (ioloop=0x80c99b0) at ioloop.c:230 #16 0x08061bc9 in main (argc=1, argv=0x0, envp=0x0) at main.c:232
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Anders Lund wrote:
Could you try to see if switching to flock would make any difference? Just remember to make sure your MTA/LDA uses at least dotlocking if you cannot switch it to use flock.
Only for "lock_method", or the other two lock methods as well?
For mbox_read_locks and mbox_write_locks since your error messages look to me as some sort of problem with mbox file locking.
But.. I was able to reproduce "file mail-index-transaction.c: line 831 (mail_index_update_ext)" assertion couple times, I made backtrace of crash and sent it to Timo. This is still very hard to reproduce ..
I'm not sure I understand. Why would I gain a lot from using Dovecot LDA? Typically users could use Procmail for filtering, and deliver to their different mboxes. I might be interested in looking at Dovecot LDA because of SIEVE, but can't see how using it will give me any big advantages.
Dovecot LDA is designed to work with Dovecot so it integrates fully with your IMAP and POP3 facility, this simplifies things a lot on any larger scale sites.
Dovecot LDA adds extra headers to every message stored in mbox on initial delivery, otherways those headers are added by IMAP or POP3 process which requires rewriting parts of mbox file causing unwanted fsynced writes.
Dovecot LDA also updates indexes on message delivery time, with mbox this is very beneficial since mbox file offsets are stored into indexes so mbox file does not need to be parsed by IMAP or POP3 process. Dovecot is altough quite clever to avoid unneeded mbox parsing even without Dovecot LDA if you have "mbox_dirty_syncs" or "mbox_very_dirty_syncs" set, but I still prefer indexing on mail delivery time.
OK. I'll add "mail_drop_priv_before_exec" and see if I get any core files.
You also need to configure your Debian to allow crashing software to create core dumps.
Edit "/etc/security/limits.conf" and uncomment line:
soft core 2000
Then check that "/etc/profile" does not have "ulimit -c 0", comment it away if it is there.
Do a relogin and type "ulimit -c", if you see "2000" then your system allowing core dumps.
-- Tomi Hakala
On Fri, 2005-10-21 at 14:47 +0200, Anders Lund wrote:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(ext->name)) == 0)
I'm not really sure about this one. If you could get the core dump from that, it would be helpful. Perhaps send me the whole core file and your imap binary (since core file itself is useless without the exact binary that produced it)?
file mail-index-sync-ext.c: line 336 (sync_ext_resize): assertion failed: (ext[i].hdr_offset > ext[i-1].hdr_offset)
This was fixed already in alpha4 (the whole assert was removed), so this must be from alpha3 or older version.
file mail-index-transaction.c: line 831 (mail_index_update_ext): assertion failed: (seq > 0 && (seq <= mail_index_view_get_messages_count(t->view) || seq <= t->last_new_seq))
Happened when trying to update X-IMAP header of the "pseudo mail" but without any other mails in the mailbox. Fixed in CVS now.
file mbox-sync-rewrite.c: line 375 (mbox_sync_read_and_move): assertion failed: (need_space == (uoff_t)-mails[idx].space)
One reason that I found for this was if the mbox file ended with message headers ending unexpectedly, eg.:
"header: value heade"
Fixed in CVS.
file mbox-sync.c: line 1295 (mbox_sync_handle_eof_updates): assertion failed: (file_size >= sync_ctx->expunged_space + trailer_size)
Same reason as above.
I can remember errors like this previously using 0.99 version of dovecot, but when using alpha3 they were gone. Any reason I get this again now?
The last two are happening because of corrupted mboxes. What is corrupting them?
Timo Sirainen wrote:
On Fri, 2005-10-21 at 14:47 +0200, Anders Lund wrote:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(ext->name)) == 0)
I'm not really sure about this one. If you could get the core dump from that, it would be helpful. Perhaps send me the whole core file and your imap binary (since core file itself is useless without the exact binary that produced it)?
I don't have any core dump of this one, but if I get one I'll run gdb on it and post the result.
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Anders Lund wrote:
Timo Sirainen wrote:
On Fri, 2005-10-21 at 14:47 +0200, Anders Lund wrote:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(ext->name)) == 0)
I'm not really sure about this one. If you could get the core dump from that, it would be helpful. Perhaps send me the whole core file and your imap binary (since core file itself is useless without the exact binary that produced it)?
I don't have any core dump of this one, but if I get one I'll run gdb on it and post the result.
Ok, here's the result of a fresh core, regarding this failure:
gdb 'bt':
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6 #1 0xb7ed5fa2 in abort () from /lib/tls/libc.so.6 #2 0x080a26d5 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:375 #3 0x080a2169 in i_panic (format=0x0) at failures.c:173 #4 0x08093246 in get_ext_header (map=0x0, ext=0x80d7ed1) at mail-index-sync-ext.c:157 #5 0x0809353b in sync_ext_reorder (map=0x80d2958, ext_id=1, old_size=2) at mail-index-sync-ext.c:273 #6 0x080937cb in sync_ext_resize (u=0x80c19a0, ext_id=1, ctx=0xbfffea10) at mail-index-sync-ext.c:340 #7 0x0809398d in mail_index_sync_ext_intro (ctx=0xbfffea10, u=0x80c19a0) at mail-index-sync-ext.c:384 #8 0x08094414 in keywords_header_add (ctx=0xbfffea10, keyword_name=0x80c16f8 "$Label1", keyword_idx_r=0x0) at mail-index-sync-keywords.c:166 #9 0x08094976 in mail_index_sync_keywords (ctx=0xbfffea10, hdr=0x0, rec=0xb7d8fc40) at mail-index-sync-keywords.c:275 #10 0x0808baa0 in mail_index_sync_record (ctx=0xbfffea10, hdr=0x80d23ec, data=0xb7d8fc40) at mail-index-sync-update.c:520 #11 0x0808bd40 in mail_index_sync_update_index (sync_ctx=0x80d1ff0, sync_only_external=0) at mail-index-sync-update.c:674 #12 0x0808a74c in mail_index_sync_commit (ctx=0x80d1ff0) at mail-index-sync.c:629 #13 0x08073f66 in mbox_sync (mbox=0x80d09e0, flags=MBOX_SYNC_UNDIRTY) at mbox-sync.c:1707 #14 0x08074374 in mbox_storage_sync_init (box=0x80d09e0, flags=MAILBOX_SYNC_FLAG_FULL_READ) at mbox-sync.c:1770 #15 0x08095a46 in mailbox_sync_init (box=0x0, flags=6) at mail-storage.c:336 #16 0x0805fe4d in imap_sync_nonselected (box=0x0, flags=0) at imap-sync.c:177 #17 0x0805810f in _cmd_select_full (cmd=0x80ca9f0, readonly=0) at cmd-select.c:39 #18 0x080582c7 in cmd_select (cmd=0x0) at cmd-select.c:92 #19 0x08059b3a in client_handle_input (cmd=0x80ca9f0) at client.c:338 #20 0x08059c5d in _client_input (context=0x80ca9b0) at client.c:390 #21 0x080a8658 in io_loop_handler_run (ioloop=0x80c99b0) at ioloop-poll.c:190 #22 0x080a7a98 in io_loop_run (ioloop=0x80c99b0) at ioloop.c:230 #23 0x08061bc9 in main (argc=1, argv=0x0, envp=0x0) at main.c:232
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Timo Sirainen wrote:
On Fri, 2005-10-28 at 13:35 +0200, Anders Lund wrote:
file mail-index-sync-ext.c: line 155 (get_ext_header): assertion failed: (memcmp((char *)(ext_hdr + 1), ext->name, strlen(ext->name)) == 0)
Fixed now in CVS.
Nice. You've fixed all of the assertions I've reported by now I think. When will a new alpha5 be released do you think? I'm not too happy about running directly from CVS...
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Anders Lund wrote:
Nice. You've fixed all of the assertions I've reported by now I think. When will a new alpha5 be released do you think? I'm not too happy about running directly from CVS...
If you do not wish to wait for alpha5 you can get up to date CVS code in neat tarball from http://www.dovecot.org/nightly/
Current CVS code has been working well for me.
-- Tomi Hakala
Tomi Hakala wrote:
Anders Lund wrote:
Nice. You've fixed all of the assertions I've reported by now I think. When will a new alpha5 be released do you think? I'm not too happy about running directly from CVS...
If you do not wish to wait for alpha5 you can get up to date CVS code in neat tarball from http://www.dovecot.org/nightly/
Current CVS code has been working well for me.
so - how close is alpha 5?
-- Marc Perkel - marc@perkel.com
Spam Filter: http://www.junkemailfilter.com My Blog: http://marc.perkel.com
Some of us are using alpha4 on production servers with thousands of users banging away. Using alpha code is pretty bleeding edge, despite the fact that dovecot works great. CVS is *too* close to the cliff and we would feel better with alpha5.
Jeff Earickson Colby College
On Mon, 31 Oct 2005, Tomi Hakala wrote:
Date: Mon, 31 Oct 2005 17:18:04 +0200 From: Tomi Hakala tomi.hakala@clinet.fi To: Anders Lund anders.lund@uninett.no Cc: dovecot@dovecot.org Subject: Re: [Dovecot] 1.0.alpha4 released
Anders Lund wrote:
Nice. You've fixed all of the assertions I've reported by now I think. When will a new alpha5 be released do you think? I'm not too happy about running directly from CVS...
If you do not wish to wait for alpha5 you can get up to date CVS code in neat tarball from http://www.dovecot.org/nightly/
Current CVS code has been working well for me.
-- Tomi Hakala
Tomi Hakala wrote:
Anders Lund wrote:
Nice. You've fixed all of the assertions I've reported by now I think. When will a new alpha5 be released do you think? I'm not too happy about running directly from CVS...
If you do not wish to wait for alpha5 you can get up to date CVS code in neat tarball from http://www.dovecot.org/nightly/
Current CVS code has been working well for me.
I updated to build from 2005-10-31 yesterday. Today for one user I get this assertion:
file buffer.c: line 230 (buffer_copy): assertion failed: (src_pos <= src->used)
(from "imap")
Result of running gdb 'bt' on this:
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6 #1 0xb7ed5fa2 in abort () from /lib/tls/libc.so.6 #2 0x080a29b5 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:375 #3 0x080a2449 in i_panic (format=0x0) at failures.c:173 #4 0x080a17ed in buffer_copy (_dest=0x80d4838, dest_pos=3086868096, _src=0x80d4838, src_pos=6767, copy_size=4294967295) at buffer.c:238 #5 0x0807664b in mbox_sync_headers_add_space (ctx=0xbfffedd0, size=5776) at mbox-sync-rewrite.c:122 #6 0x08076a94 in mbox_sync_try_rewrite (ctx=0xbfffedd0, move_diff=0) at mbox-sync-rewrite.c:252 #7 0x08072227 in mbox_sync_handle_header (mail_ctx=0xbfffedd0) at mbox-sync.c:736 #8 0x08072a74 in mbox_sync_loop (sync_ctx=0xbfffeed0, mail_ctx=0xbfffedd0, partial=1) at mbox-sync.c:1106 #9 0x08073852 in mbox_sync_do (sync_ctx=0xbfffeed0, flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1447 #10 0x08073f0c in mbox_sync (mbox=0x80d19d8, flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1694 #11 0x0806c4c6 in mbox_storage_close (box=0x80d19d8) at mbox-storage.c:973 #12 0x08095c0f in mailbox_close (box=0x0) at mail-storage.c:303 #13 0x0805825b in _cmd_select_full (cmd=0x80ca9f0, readonly=0) at cmd-select.c:24 #14 0x08058297 in cmd_select (cmd=0x0) at cmd-select.c:92 #15 0x08059b0a in client_handle_input (cmd=0x80ca9f0) at client.c:338 #16 0x08059c2d in _client_input (context=0x80ca9b0) at client.c:390 #17 0x080a8938 in io_loop_handler_run (ioloop=0x80c99b0) at ioloop-poll.c:190 #18 0x080a7d78 in io_loop_run (ioloop=0x80c99b0) at ioloop.c:230 #19 0x08061bb9 in main (argc=1, argv=0x0, envp=0x0) at main.c:233
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Anders Lund wrote:
Tomi Hakala wrote:
Anders Lund wrote:
Nice. You've fixed all of the assertions I've reported by now I think. When will a new alpha5 be released do you think? I'm not too happy about running directly from CVS...
If you do not wish to wait for alpha5 you can get up to date CVS code in neat tarball from http://www.dovecot.org/nightly/
Current CVS code has been working well for me.
I updated to build from 2005-10-31 yesterday. Today for one user I get this assertion:
file buffer.c: line 230 (buffer_copy): assertion failed: (src_pos <= src->used)
(from "imap")
Another assertion with this nightly build from CVS:
file mbox-sync.c: line 1297 (mbox_sync_handle_eof_updates): assertion failed: (file_size >= sync_ctx->expunged_space + trailer_size)
gdb 'bt' gives:
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6 #1 0xb7ed5fa2 in abort () from /lib/tls/libc.so.6 #2 0x080a29b5 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:375 #3 0x080a2449 in i_panic (format=0x0) at failures.c:173 #4 0x08072fa5 in mbox_sync_handle_eof_updates (sync_ctx=0xb7fdde80, mail_ctx=0xbfffe800) at mbox-sync.c:1320 #5 0x08073865 in mbox_sync_do (sync_ctx=0xbfffe900, flags=MBOX_SYNC_UNDIRTY) at mbox-sync.c:1467 #6 0x08073f0c in mbox_sync (mbox=0x80d4ad0, flags=MBOX_SYNC_UNDIRTY) at mbox-sync.c:1694 #7 0x08074384 in mbox_storage_sync_init (box=0x80d4ad0, flags=MAILBOX_SYNC_FLAG_FULL_READ) at mbox-sync.c:1772 #8 0x08095cc6 in mailbox_sync_init (box=0x0, flags=6) at mail-storage.c:336 #9 0x0805fe1d in imap_sync_nonselected (box=0x0, flags=0) at imap-sync.c:177 #10 0x080580df in _cmd_select_full (cmd=0x80ca9f0, readonly=0) at cmd-select.c:39 #11 0x08058297 in cmd_select (cmd=0x0) at cmd-select.c:92 #12 0x08059b0a in client_handle_input (cmd=0x80ca9f0) at client.c:338 #13 0x08059c2d in _client_input (context=0x80ca9b0) at client.c:390 #14 0x080a8938 in io_loop_handler_run (ioloop=0x80c99b0) at ioloop-poll.c:190 #15 0x080a7d78 in io_loop_run (ioloop=0x80c99b0) at ioloop.c:230 #16 0x08061bb9 in main (argc=1, argv=0x0, envp=0x0) at main.c:233
BTW, is it OK to send this to the list or do you prefere that I send these dumps to some other address?
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Anders Lund wrote:
I updated to build from 2005-10-31 yesterday. Today for one user I get this assertion:
file buffer.c: line 230 (buffer_copy): assertion failed: (src_pos <= src->used)
(from "imap")
Another assertion with this nightly build from CVS:
file mbox-sync.c: line 1297 (mbox_sync_handle_eof_updates): assertion failed: (file_size >= sync_ctx->expunged_space + trailer_size)
And another new assertion with the same version of Dovecot from CVS:
file mbox-sync-rewrite.c: line 383 (mbox_sync_read_and_move): assertion failed: (seq == mail_ctx->seq)
gdb 'bt':
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6 #1 0xb7ed5fa2 in abort () from /lib/tls/libc.so.6 #2 0x080a29b5 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:375 #3 0x080a2449 in i_panic (format=0x0) at failures.c:173 #4 0x080770bd in mbox_sync_read_and_move (sync_ctx=0xbfffee20, mail_ctx=0xbfffed20, mails=0x81426f8, seq=381, idx=0, padding=100, move_diff=101, expunged_space=0, end_offset=48251918, first_nonexpunged=1) at mbox-sync-rewrite.c:416 #5 0x080777a0 in mbox_sync_rewrite (sync_ctx=0xbfffee20, mail_ctx=0xbfffed20, end_offset=48251918, move_diff=101, extra_space=100, first_seq=381, last_seq=1) at mbox-sync-rewrite.c:501 #6 0x080723e1 in mbox_sync_handle_missing_space (mail_ctx=0xbfffed20) at mbox-sync.c:827 #7 0x08072c02 in mbox_sync_loop (sync_ctx=0xbfffee20, mail_ctx=0xbfffed20, partial=1) at mbox-sync.c:1127 #8 0x08073852 in mbox_sync_do (sync_ctx=0xbfffee20, flags=25) at mbox-sync.c:1447 #9 0x08073f0c in mbox_sync (mbox=0x80ee158, flags=25) at mbox-sync.c:1694 #10 0x0806c612 in mbox_transaction_commit (_t=0x813fbc8, flags=3) at mbox-transaction.c:56 #11 0x08095eb8 in mailbox_transaction_commit (t=0x6, flags=0) at mail-storage.c:421 #12 0x0805ac4c in imap_expunge (box=0x0, next_search_arg=0x0) at imap-expunge.c:44 #13 0x08055be1 in cmd_close (cmd=0x80ca9f0) at cmd-close.c:20 #14 0x08059b0a in client_handle_input (cmd=0x80ca9f0) at client.c:338 #15 0x08059c2d in _client_input (context=0x80ca9b0) at client.c:390 #16 0x080a8938 in io_loop_handler_run (ioloop=0x80c99b0) at ioloop-poll.c:190 #17 0x080a7d78 in io_loop_run (ioloop=0x80c99b0) at ioloop.c:230 #18 0x08061bb9 in main (argc=1, argv=0x0, envp=0x0) at main.c:233
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
Anders Lund wrote:
Anders Lund wrote:
I updated to build from 2005-10-31 yesterday. Today for one user I get this assertion:
file buffer.c: line 230 (buffer_copy): assertion failed: (src_pos <= src->used)
(from "imap")
Another assertion with this nightly build from CVS:
file mbox-sync.c: line 1297 (mbox_sync_handle_eof_updates): assertion failed: (file_size >= sync_ctx->expunged_space + trailer_size)
And another new assertion with the same version of Dovecot from CVS:
file mbox-sync-rewrite.c: line 383 (mbox_sync_read_and_move): assertion failed: (seq == mail_ctx->seq)
Another new one:
file mbox-sync-rewrite.c: line 400 (mbox_sync_read_and_move): assertion failed: (need_space == (uoff_t)-mails[idx].space)
gdb 'bt':
#0 0xb7ed483b in raise () from /lib/tls/libc.so.6 #1 0xb7ed5fa2 in abort () from /lib/tls/libc.so.6 #2 0x080a29b5 in i_internal_panic_handler (fmt=0x0, args=0x0) at failures.c:375 #3 0x080a2449 in i_panic (format=0x0) at failures.c:173 #4 0x080770bd in mbox_sync_read_and_move (sync_ctx=0xbfffe8a0, mail_ctx=0xbfffe550, mails=0x80d8130, seq=0, idx=1, padding=2, move_diff=8, expunged_space=0, end_offset=28255, first_nonexpunged=0) at mbox-sync-rewrite.c:416 #5 0x080777a0 in mbox_sync_rewrite (sync_ctx=0xbfffe8a0, mail_ctx=0x0, end_offset=28255, move_diff=8, extra_space=8, first_seq=12, last_seq=0) at mbox-sync-rewrite.c:501 #6 0x080723e1 in mbox_sync_handle_missing_space (mail_ctx=0xbfffe7a0) at mbox-sync.c:827 #7 0x08072c02 in mbox_sync_loop (sync_ctx=0xbfffe8a0, mail_ctx=0xbfffe7a0, partial=1) at mbox-sync.c:1127 #8 0x08073852 in mbox_sync_do (sync_ctx=0xbfffe8a0, flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1447 #9 0x08073f0c in mbox_sync (mbox=0x80d09e8, flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1694 #10 0x0806c4c6 in mbox_storage_close (box=0x80d09e8) at mbox-storage.c:973 #11 0x08095c0f in mailbox_close (box=0x0) at mail-storage.c:303 #12 0x080579b8 in cmd_logout (cmd=0x80ca9f0) at cmd-logout.c:18 #13 0x08059b0a in client_handle_input (cmd=0x80ca9f0) at client.c:338 #14 0x08059c2d in _client_input (context=0x80ca9b0) at client.c:390 #15 0x080a8938 in io_loop_handler_run (ioloop=0x80c99b0) at ioloop-poll.c:190 #16 0x080a7d78 in io_loop_run (ioloop=0x80c99b0) at ioloop.c:230 #17 0x08061bb9 in main (argc=1, argv=0x0, envp=0x0) at main.c:233
- Anders
--
Anders Lund Anders.Lund@uninett.no .~.
UNINETT, N-7465 Trondheim, Norway / V
Phone: +47 73 55 79 08 | Fax: +47 73 55 79 01 /( )
^ ^
participants (9)
-
Anders Lund
-
Jeff A. Earickson
-
Johannes Berg
-
Marc Perkel
-
Pasi Sjoholm
-
Sebastjan Trepca
-
Timo Sirainen
-
Todd Burroughs
-
Tomi Hakala