Re: [Dovecot] Assertion failed with imapc after upgrading Dovecot from 2.1.7 to 2.2.9
Hi !
I would like to jump to version 2.2.9 instead of 2.1.7 to avoid maybe
hundred of segfault by day but my problem with the assertion is always here.
Anyone has an idea to resolve it ?
Sylvain
2014-01-07 Sylvain debian.r...@gmail.com
Hi !
I have an old Courier IMAP and in front of it, I have put a proxy cache
with Dovecot/imapc.
I use Debian Wheezy (stable) which package Dovecot in version 2.1.7.
I have tested the upgrade to Debian Jessie (testing) which package Dovecot
in version 2.2.9 but an assertion is thrown :
dovecot: imap(xxx): Panic: file imapc-list.c: line 499
(imapc_list_delete_unused_indexes): assertion failed: (strncmp(vname,
fs_list-ns-prefix, fs_list-ns-prefix_len) == 0)
I have checked source code and have seen that if *imapc_list_prefix* is
not set, assertion will not be walked. It's works but special inbox
aren't detected correctly in email clients.
If I understand the meaning of *vname* variable, it is because our
Courier IMAP send us INBOX which is the value of my *imapc_list_prefix*and
thus, assertion is thrown.
Here some details of my tests :
Courier IMAP :
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION
STARTTLS] Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc.
See COPYING for distribution information.
a login xxx xxx
a OK LOGIN Ok.
a list *
* LIST (\HasNoChildren) . INBOX.Drafts
* LIST (\HasNoChildren) . INBOX.Trash
* LIST (\HasNoChildren) . INBOX.test
* LIST (\HasNoChildren) . INBOX.Sent
* LIST (\HasNoChildren) . INBOX.Junk
* LIST (\Unmarked \HasChildren) . INBOX
a OK LIST completed
Dovecot version 2.1.7 :
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a login xxx xxx
a OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT
CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC
ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE]
Logged in
a list *
* LIST (\HasChildren) . INBOX
* LIST (\HasNoChildren \Drafts) . INBOX.Drafts
* LIST (\HasNoChildren \Trash) . INBOX.Trash
* LIST (\HasNoChildren) . INBOX.test
* LIST (\HasNoChildren \Sent) . INBOX.Sent
* LIST (\HasNoChildren \Junk) . INBOX.Junk
a OK List completed.
Dovecot version 2.2.9 :
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
a login xxx xxx
a OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT
MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS
LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN
CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE] Logged in
a list *
Connection closed by foreign host.
And the dovecot configuration relative to the inbox :
imapc_list_prefix = INBOX
namespace inbox {
inbox = yes
separator = .
prefix = INBOX.
}
Any help will be welcome :)
Sylvain
Re: [Dovecot] assertion failed: (uidmap[src].real_uid == uid)
On Thu, 2013-01-03 at 19:13 +0800, Chris Vanden Berghe wrote:
Hi all,
Does anyone have an idea what could cause the below error?
Dec 31 17:03:46 bobodioulasso dovecot: imap(b...@bla.org): Panic: file
virtual-sync.c: line 542 (virtual_sync_mailbox_box_remove): assertion
failed: (uidmap[src].real_uid == uid)
Looks like a bug in virtual plugin. Those are a bit difficult to debug
though. It would be very helpful if I could reproduce this myself. I'd
need some files from the user's mailbox for that (not the mail files, so
nothing sensitive). But..:
The error only occurs for a single user on the system. This user uses
Apple Mail client.
..
namespace {
inbox = yes
location = maildir:/var/vmail/%u
prefix =
separator = .
}
namespace {
location = virtual:/var/vmail/virtual
prefix = virtual.
separator = .
}
This isn't a good setup. Now each user recreates the entire virtual
mailbox every time it's opened. Maybe the bug is related to that. Use
instead something like:
namespace {
location = virtual:/var/vmail/virtual:INDEX=/var/vmail/%u/virtual
Re: [Dovecot] assertion failed in mail-index.c
On Wed, 2012-01-04 at 16:19 +0100, Attila Nagy wrote:
Hi,
I have this:
Jan 04 15:55:21 pop3(jfm47): Panic: file mail-index.c: line 257
(mail_index_keyword_lookup_or_create): assertion failed: (*keyword != '\0')
Jan 04 15:55:21 master: Error: service(pop3): child 3391 killed with
signal 6 (core not dumped - set service pop3 { drop_priv_before_exec=yes })
I don't know why this happened, but wouldn't be the self healing (seen
in the wiki I think :) kick in here?
I mean it's even better to completely remove the index than dying and
make the mailbox inaccessible.
See if http://hg.dovecot.org/dovecot-2.0/raw-rev/5ef791398c8c helps. If
not, I'd need a gdb backtrace to find out what is causing it:
http://dovecot.org/bugreport.html
Re: [Dovecot] assertion failed: (auth_request_state_count[request-state] 0)
On Thu, 2010-10-14 at 12:18 -0500, Mike Abbott wrote: Thu Oct 14 10:09:39 server dovecot[150]: auth: Panic: file auth-request.c: line 78 (auth_request_set_state): assertion failed: (auth_request_state_count[request-state] 0) Well, I'm not entirely sure but maybe http://hg.dovecot.org/dovecot-2.0/rev/0b509f1ee95c fixes this. A good idea anyway to do it. :)
Re: [Dovecot] Assertion failed in mail-search-build.c
On Mon, 2010-04-26 at 10:15 -0700, Mark Moseley wrote: Apr 26 12:58:34 imap(m...@box): Panic: file mail-search-build.c: line 59 (mail_search_build_key_int): assertion failed: (sarg-value.subargs != NULL) Thanks, fixed: http://hg.dovecot.org/dovecot-2.0/rev/888ac9037642 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed while using sieve
On Thu, 2009-09-03 at 22:38 +0200, Maciej Uhlig wrote: Timo Sirainen wrote: Can you try if the attached patch fixes this We did try. Unfortunately the problem is still there. Same error. Can you easily reproduce it? How? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed while using sieve
Timo Sirainen wrote: Can you try if the attached patch fixes this We did try. Unfortunately the problem is still there. Same error. Best regards, MU
Re: [Dovecot] assertion failed while using sieve
let me provide some more findings: first, the script which uses require body crashes too for some mails while running as a script for individual user. second, we found the test mail example which causes this crash every time. please let me know if you're interested in the mail source, I'd send it to the given address. Regards, MU
Re: [Dovecot] assertion failed while using sieve
On Tue, 2009-09-01 at 12:19 +0200, Maciej Uhlig wrote:
2009-09-01T02:40:57+02:00 prac/prac dovecot: [ID 583609 mail.crit]
deliver(i...@domain): Panic: file ext-body-common.c: line 149: assertion
failed: (buf-used - 1 == part-body_size.physical_size)
Can you try if the attached patch fixes this?
diff -r a8c962e603be src/lib-sieve/plugins/body/ext-body-common.c
--- a/src/lib-sieve/plugins/body/ext-body-common.c Mon Aug 31 01:18:05 2009 +0200
+++ b/src/lib-sieve/plugins/body/ext-body-common.c Wed Sep 02 10:54:12 2009 -0400
@@ -203,7 +203,7 @@
decoder = decode_to_plain ? message_decoder_init(FALSE) : NULL;
parser = message_parser_init
- (ctx-pool, input, 0, MESSAGE_PARSER_FLAG_SKIP_BODY_BLOCK);
+ (ctx-pool, input, 0, 0);
while ( (ret = message_parser_parse_next_block(parser, block)) 0 ) {
if ( block.part != prev_part ) {
/* Save previous body part */
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Tue, 2009-02-17 at 18:28 +, Ian P. Christian wrote: Does anyone know what might cause this? # dovecot --version 1.1.7 Feb 17 18:21:51 imap-proxy-temp dovecot: Panic: auth(default): file passdb-cache.c: line 121 (passdb_cache_lookup_credentials): assertion failed: (*scheme_r != NULL || *password_r == NULL) dovecot -n output? Anyway, I remember fixing something related to this recently, so simply upgrading will probably fix it. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Tue, 2009-02-17 at 19:32 +, Ian P. Christian wrote: 2009/2/17 Timo Sirainen t...@iki.fi: dovecot -n output? Anyway, I remember fixing something related to this recently, so simply upgrading will probably fix it. Thanks for the quick reply. Unfortunately an upgrade to 1.1.11 hasn't sorted it. Could you do one more thing: Set auth_debug=yes and paste the logs what happens before the crash. Also show what you have in password_query in dovecot-sql.conf. Are you using mysql? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
2009/2/17 Timo Sirainen t...@iki.fi: Could you do one more thing: Set auth_debug=yes and paste the logs what happens before the crash. Also show what you have in password_query in dovecot-sql.conf. Are you using mysql? These were sent offlist. One thing I really should have mentioned is that these errors only happen about 200-250 times a day, on a very busy server.
Re: [Dovecot] assertion failed in 1.1.7 file mbox-sync.c: line 1305 (mbox_sync_handle_eof_updates)
On Thu, Dec 4, 2008 at 8:26 AM, Diego Liziero diego...@gmail.com wrote: Dovecot 1.1.7 is running so smoothly that I gave up checking its log files daily. :) I've just had a look, and among the usual IMAP(username): FETCH for mailbox Sent UID xx got too little data: xx vs xx messages (that means that unfortunately sometimes some messages are still written truncated) I saw this assertion failure: file mbox-sync.c: line 1305 (mbox_sync_handle_eof_updates): assertion failed: (file_size = sync_ctx-expunged_space + trailer_size) Btw: (gdb) fr 6 #6 0x080911de in mbox_sync_handle_eof_updates (sync_ctx=0xbfbac0f4, mail_ctx=0xbfbac008) at mbox-sync.c:1305 1305i_assert(file_size = sync_ctx-expunged_space + trailer_size); (gdb) print file_size $1 = 242 (gdb) print sync_ctx-expunged_space $2 = 243 (gdb) print trailer_size $3 = 0 Regards, Diego.
Re: [Dovecot] assertion failed
On Wed, 2008-12-03 at 14:14 +0100, Antonio Casado RodrÃguez wrote: Hi all, I have seen this in log: dovecot: Dec 03 06:12:57 Error: IMAP(maurirrr): file mail-index-view-sync.c: line 666 (mail_index_view_sync_end): asser tion failed: (view-log_file_offset = view-map-hdr.log_file_int_offset) .. # 1.0.13: /etc/dovecot.conf v1.1 has a lot of fixes related to index file handling. This anyway shouldn't be a real problem unless it happens all the time. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timo, From other posts it seems to be when you are moving message. I have tried and cannot get it to happen with my account. I tried with Thunderbird, SquirrellMail, and Mac Mail. Out of 620K of log file lines the error only occurred 81 times yesterday. I will keep an eye on it, and try to find a user that I know I can work with that is getting the error. Timo Sirainen wrote: On Thu, 2008-08-21 at 16:27 -0600, CJ Keist wrote: I haven't heard anything on this bug. Is this a bug? I'm using dovecot 1.1.2 with the following patch applied: http://hg.dovecot.org/dovecot-1.1/rev/d674c05d725d Another section from my logs. I know the backtrace is just numbers, let me know how to compile to get more useful information if you need it. So far no one is beating down my door, so I don't think users are seeing any ill effects. But I would sleep better knowing why it's happening. Aug 21 16:19:17 goku dovecot: [ID 107833 mail.crit] Panic: IMAP(rhjohn): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion Yes, it's a bug. Can you reproduce it in any way? v1.1.2 was supposed to fix this for some people, not cause it to happen more often. You can always just comment out that line, it won't really break anything. - -- C. J. Keist Email: [EMAIL PROTECTED] UNIX/Network ManagerPhone: 970-491-0630 Engineering Network ServicesFax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301 All I want is a chance to prove 'Money can't buy happiness' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrtCFA29OFr7C6jcRApaTAJ9UFANFdUGZ0Wy5C4CipPlw41rsagCfV5ye rVqQMgyeLVTljR3hQyRw1g0= =xbwh -END PGP SIGNATURE-
Re: [Dovecot] assertion failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Spoke too soon, I think I have a way to reproduce the error. Here are the steps: 1. Exit out of thunderbird 2. delete mail/.imap folder 3. Restart thunderbird 4. delete a message ( I have setting so that message are moved to Trash when deleted) At that point I get the assertion error in the log files. I'm three for three so far doing this way. Though this could be normal for first time creating the index files in .imap? Timo Sirainen wrote: On Thu, 2008-08-21 at 16:27 -0600, CJ Keist wrote: I haven't heard anything on this bug. Is this a bug? I'm using dovecot 1.1.2 with the following patch applied: http://hg.dovecot.org/dovecot-1.1/rev/d674c05d725d Another section from my logs. I know the backtrace is just numbers, let me know how to compile to get more useful information if you need it. So far no one is beating down my door, so I don't think users are seeing any ill effects. But I would sleep better knowing why it's happening. Aug 21 16:19:17 goku dovecot: [ID 107833 mail.crit] Panic: IMAP(rhjohn): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion Yes, it's a bug. Can you reproduce it in any way? v1.1.2 was supposed to fix this for some people, not cause it to happen more often. You can always just comment out that line, it won't really break anything. - -- C. J. Keist Email: [EMAIL PROTECTED] UNIX/Network ManagerPhone: 970-491-0630 Engineering Network ServicesFax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301 All I want is a chance to prove 'Money can't buy happiness' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrtoDA29OFr7C6jcRAoBBAKDhPqk7Q/OVlILXoWk+KoY98S5HLgCgwXSZ 71QdwvwxtpDJEb5J49OEu7Y= =/AlA -END PGP SIGNATURE-
Re: [Dovecot] assertion failed
On 8/19/2008, CJ Keist ([EMAIL PROTECTED]) wrote: I just switched over to dovecot 1.1.2 on our live system last night. What version were you on before (might tell Timo something)? -- Best regards, Charles
Re: [Dovecot] assertion failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I had the wrong link below, this is the correct URL I used to patch the 1.1.2 source tree: http://hg.dovecot.org/dovecot-1.1/rev/d674c05d725d - - I believe the is the fix I did to the 1.1.2 source code: http://hg.dovecot.org/dovecot-1.1/rev/65d1fc48224d Charles Marcus wrote: On 8/19/2008, CJ Keist ([EMAIL PROTECTED]) wrote: I just switched over to dovecot 1.1.2 on our live system last night. What version were you on before (might tell Timo something)? - -- C. J. Keist Email: [EMAIL PROTECTED] UNIX/Network ManagerPhone: 970-491-0630 Engineering Network ServicesFax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301 All I want is a chance to prove 'Money can't buy happiness' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIqzgUA29OFr7C6jcRAjjGAKCCiOkd/t9+6QNVeioGdydCdhxV2ACfRWxC dWAm8MiIOsRAmnh8ilTUmb0= =EY78 -END PGP SIGNATURE-
Re: [Dovecot] assertion failed: (seq = t-first_new_seq seq = t-last_new_seq)
On Thu, 2008-07-03 at 15:42 +0100, Mark Zealey wrote: OK I've been struggling to get dumps from the live environment most of the day, but have given up. I've now managed to reproduce this using a fork-bomb type script; here is a backtrace (no debug version installed, but I suspect I could reproduce this in the dev environment if it's not clear what the error is). The backtrace was somewhat broken, but I think I figured out the problem (although I couldn't reproduce it). See if this fixes: http://hg.dovecot.org/dovecot-1.1/rev/65d1fc48224d signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed: (seq = t-first_new_seq seq = t-last_new_seq)
On Jul 3, 2008, at 2:42 PM, Mark Zealey wrote: Hi guys, Anyone know what this error with deliver is (v1.1.1)? 2008-07-03T09:45:19+01:00 mail4 deliver(alexander): Panic: file mail-index-transaction.c: line 642 (mail_index_transaction_lookup): assertion failed: (seq = t-first_new_seq seq = t-last_new_seq) Could you get gdb backtrace from this? Although depending on your configuration it might be tricky to get core dumps.. http://dovecot.org/bugreport.html has some ideas, but it doesn't really talk about deliver. I guess the main things are: - user should have a writable home directory (where the core is written to) - run ulimit -c unlimited before running your MTA PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] assertion failed: (seq = t-first_new_seq seq = t-last_new_seq)
OK I've been struggling to get dumps from the live environment most of the day, but have given up. I've now managed to reproduce this using a fork-bomb type script; here is a backtrace (no debug version installed, but I suspect I could reproduce this in the dev environment if it's not clear what the error is). (gdb) bt #0 0x004ef402 in __kernel_vsyscall () #1 0x00138c00 in raise () from /lib/libc.so.6 #2 0x0013a451 in abort () from /lib/libc.so.6 #3 0x080c413d in default_error_handler () #4 0x080c41cd in i_syslog_fatal_handler () #5 0x080c3a2c in i_panic () #6 0x080a072c in mail_index_transaction_lookup () #7 0x080a39d7 in mail_index_transaction_open_updated_view () #8 0x080b2853 in mail_cache_decision_add () #9 0x0809b884 in mail_cache_add () #10 0x08089910 in index_mail_cache_add_idx () #11 0x08089a03 in index_mail_cache_add () #12 0x08089ec7 in index_mail_close () #13 0x0808ad90 in index_mail_free () #14 0x08092f42 in mail_free () #15 0x0806c63c in maildir_transaction_save_commit_pre () #16 0x08065d62 in maildir_transaction_class_deinit () #17 0x08092cce in index_transaction_commit () #18 0x08094a56 in mailbox_transaction_commit () #19 0x0805a416 in deliver_save () #20 0x0805b99a in main () The way I caused this crash was: [EMAIL PROTECTED] tmp]# cat t.sh #!/bin/bash HOME=/path/to/nfs/Maildir/ export HOME exec /usr/libexec/dovecot/deliver -f [EMAIL PROTECTED] Then in bash as root: # i=0; while true; do echo $i; i=$((i+1)); sudo -u exim /tmp/t.sh /root/t sudo -u exim /tmp/t.sh /root/t sudo -u exim /tmp/t.sh /root/t sudo -u exim /tmp/t.sh /root/t sudo -u exim /tmp/t.sh /root/t sudo -u exim /tmp/t.sh /root/t done After about 3 seconds I got 10 crashes and core dumps. A word about our setup; we have the maildirs stored on an nfs mount and deliver could be called on multiple heads at the same time for deliveries - I suspect this is what was causing the problem. Our nfs mount options are rw,noatime,nodiratime,hard,intr,rsize=32768,wsize=32768,tcp,nocto. Running centos 5.1 on the boxes with exim. Thanks, Mark
Re: [Dovecot] assertion failed: (mailbox_list_is_valid_existing_name(_list, name))
On Sun, Nov 11, 2007 at 12:57:21AM -0500, Adam McDougall wrote: Do you need a gdb backtrace for this one? I'm not sure why all of a sudden this started happening, its probably due to me adding a folder somewhere? not sure. It happened when I went to open my folder subscriptions in thunderbird. It was taking longer than usual (call this phase 1) and I noticed this in the logs: (cant remember if this was phase 1 or 2 but the error is probably the same) Nov 11 00:38:38 boomhauer dovecot: imap-login: Login: user=mcdouga9, method=PLAIN, rip=208.53.102.126, lip=35.9.37.190, TLS Nov 11 00:38:39 boomhauer dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.boomhauer.3050.af3db3ac545170a7) failed: Operation not permitted Nov 11 00:38:44 boomhauer dovecot: IMAP(mcdouga9): file mailbox-list-maildir.c: line 186 (maildir_list_get_path): assertion failed: (mailbox_list_is_valid_existing_name(_list, name)) Nov 11 00:38:44 boomhauer dovecot: child 3050 (imap) killed with signal 6 Nov 11 00:38:45 boomhauer dovecot: imap-login: Login: user=mcdouga9, method=PLAIN, rip=208.53.102.126, lip=35.9.37.190, TLS Nov 11 00:38:45 boomhauer dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.boomhauer.3052.5538be060c2f9c7d) failed: Operation not permitted Nov 11 00:38:46 boomhauer dovecot: IMAP(mcdouga9): file mailbox-list-maildir.c: line 186 (maildir_list_get_path): assertion failed: (mailbox_list_is_valid_existing_name(_list, name)) Nov 11 00:38:46 boomhauer dovecot: child 3052 (imap) killed with signal 6 When I cancelled the subscription window, phase 2 is the same thing but happening more rapidly. I traced what tbird is doing and can reproduce it with: ? OK Logged in. a list #shared/decs/%/% Connection closed by foreign host. Doing a list on #shared/decs/% works though. I found why this happens. I had accidently created a maildir with a dot at the end of its name due to a bug in a script. Can be reproduced with mkdir /egr/mail/shared/decs/.foo. Crashes go away when I deleted the directory.
Re: [Dovecot] assertion failed: (mailbox_list_is_valid_existing_name(_list, name))
On Sun, 2007-11-11 at 03:47 -0500, Adam McDougall wrote: Nov 11 00:38:46 boomhauer dovecot: IMAP(mcdouga9): file mailbox-list-maildir.c: line 186 (maildir_list_get_path): assertion failed: (mailbox_list_is_valid_existing_name(_list, name)) I found why this happens. I had accidently created a maildir with a dot at the end of its name due to a bug in a script. Can be reproduced with mkdir /egr/mail/shared/decs/.foo. Crashes go away when I deleted the directory. I guess the best way now to handle this is just to remove the assert.. http://hg.dovecot.org/dovecot/rev/8d6a70a42830 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Assertion failed: (pos input-size)
On Sun, 21 Oct 2007, Asheesh Laroia wrote: Well, hg bisect doesn't seem to be helping me find the answer. I fear that the real problem is in base64_decode, but for now I'm going to sleep instead of drowsily being confused by a debugger. For what it's worth, http://paulproteus.acm.jhu.edu/bug-report/2007-10-22/index_crash.tar.gz causes this assertion fail consistently. This is a tarred-up Maildir (with Dovecot metadata you can feel free to remove) with one message in it. I don't currently have a clue what's going on, but having a small test case may be of use. -- Asheesh. -- Help! I'm trapped in a Chinese computer factory!
Re: [Dovecot] Assertion failed: (pos input-size)
On 22.10.2007, at 6.46, Asheesh Laroia wrote: I'm looking at this in ddd, but my compile of Dovecot doesn't seem to have the pos local anymore, which is extremely confusing. Compiler optimizations make debugging difficult. I usually recompile the files I want to debug without -O2 by removing it from CFLAGS in their Makefiles and either make clean or update files' timestamps. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Assertion failed: (pos input-size)
On Sun, 21 Oct 2007, Asheesh Laroia wrote:
I fear that the real problem is in base64_decode, but for now I'm going
to sleep instead of drowsily being confused by a debugger.
When I add the attached patch, which just adds two asserts toward the end
of base64_decode(), I can get base64_decode to admit that it advanced the
pos pointer beyond where it should be.
The asserts are src_pos = src_size because the loops will advance src_pos
to the point where it is == src_size. It'd be nice if that didn't happen,
and the value of src_pos were always valid, but here I've shown that it
gets advanced even beyond == !
(Earlier, I was asserting src_pos src_size, and then every use of
base64_decode caused the assertion to fail, so I couldn't even log in.)
I'm still testing with the Maildir I linked to last night.
It'd be great to know if these new asserts are reasonable, and if so, what
sorts of code changes might make them stop failing. (-:
-- Asheesh.
--
It has long been an axiom of mine that the little things are infinitely
the most important.
-- Sir Arthur Conan Doyle, A Case of Identitydiff -r 1478fc5cf632 src/lib/base64.c
--- a/src/lib/base64.c Sun Oct 21 20:36:35 2007 +0300
+++ b/src/lib/base64.c Mon Oct 22 10:11:40 2007 -0700
@@ -128,6 +128,8 @@ int base64_decode(const void *src, size_
buffer_append(dest, output, 3);
}
+ i_assert(src_pos = src_size);
+
for (; src_pos src_size; src_pos++) {
if (!IS_EMPTY(src_c[src_pos]))
break;
@@ -136,6 +138,7 @@ int base64_decode(const void *src, size_
if (src_pos_r != NULL)
*src_pos_r = src_pos;
+ i_assert(src_pos = src_size);
return ret;
}
Re: [Dovecot] Assertion failed: (pos input-size)
On Mon, 22 Oct 2007, Timo Sirainen wrote: On Mon, 2007-10-22 at 10:16 -0700, Asheesh Laroia wrote: On Sun, 21 Oct 2007, Asheesh Laroia wrote: I fear that the real problem is in base64_decode, but for now I'm going to sleep instead of drowsily being confused by a debugger. When I add the attached patch, which just adds two asserts toward the end of base64_decode(), I can get base64_decode to admit that it advanced the pos pointer beyond where it should be. I guess this fixes it: http://hg.dovecot.org/dovecot/rev/d81a50101724 Indeed it does! Super fast searches are go, and seem to give the right results. (-: In fact, SEARCH TEXT (instantaneous) seems to be a lot faster than SEARCH FROM (a few seconds) right now! -- Asheesh. -- Out of sight is out of mind. -- Arthur Clough
Re: [Dovecot] assertion failed: (mailbox_list_is_valid_existing_name(_list, name))
On Sun, Oct 21, 2007 at 01:09:43PM -0400, Adam McDougall wrote: When I was initially testing dovecot 1.1b2,3 I had ACLs turned on and encountered this problem below. I had them turned off until now, I'll need to have ACLs working before I can widen testing. I'm not sure how to make env MAIL=maildir:~/Maildir gdb /tmp/imap load the ACL plugin so I assume that is why it does not crash; not getting any log either from that, maybe I made a mistake? But when running mutt, I can load it up with the inbox, then when I ask for imap://server/mail/ it crashes with the assertion at the bottom. Let me know if I need to provide more info. Thanks. Oct 21 12:57:20 gribble dovecot: IMAP(mcdouga9): acl vfile: file /home/mcdouga9/Maildir/dovecot-acl not found Oct 21 12:57:20 gribble dovecot: IMAP(mcdouga9): file mailbox-list-maildir.c: line 186 (maildir_list_get_path): assertion failed: (mailbox_list_is_valid_existing_name(_list, name)) Oct 21 12:57:20 gribble dovecot: child 72205 (imap) killed with signal 6 I forgot to mention, heres the command trace: a0006 LIST mail * LIST (\Noselect \HasChildren) / mail a0006 OK List completed. a0007 LIST mail/% (disconnected)
Re: [Dovecot] Assertion failed: (pos input-size)
On Sun, 21 Oct 2007, Timo Sirainen wrote: have to run out and buy ingredients for a birthday cake, so I thought I'd email this very terse message to the list in case it was some help, I'd also have to start studying for tuesday's exam (100+ pages about proteins) soon if I intend to pass it.. :) So *that* explains all the Dovecot work! Needless to say, I'd love it if you fixed this. (-: -- Asheesh. -- There are two ways to write error-free programs; only the third one works.
Re: [Dovecot] Assertion failed: (pos input-size)
On Sun, 21 Oct 2007, Timo Sirainen wrote: Looks like I can get the same crash with my INBOX also. have to run out and buy ingredients for a birthday cake, so I thought I'd email this very terse message to the list in case it was some help, I'd also have to start studying for tuesday's exam (100+ pages about proteins) soon if I intend to pass it.. :) I'm looking at this in ddd, but my compile of Dovecot doesn't seem to have the pos local anymore, which is extremely confusing. Do you want help with this? I'm going to see if hg bisecting (the latest tool I have...) is any use. If you know what the problem is and don't need help, feel free to let me know! -- Asheesh. -- Very few profundities can be expressed in less than 80 characters.
Re: [Dovecot] Assertion failed: (pos input-size)
On Sun, 21 Oct 2007, Asheesh Laroia wrote: I'm looking at this in ddd, but my compile of Dovecot doesn't seem to have the pos local anymore, which is extremely confusing. Still can't find it. I'm very confused. PEBKAC is possible but I don't see how. It may have something to do with the way scope works inside switch statement cases. Do you want help with this? I'm going to see if hg bisecting (the latest tool I have...) is any use. If you know what the problem is and don't need help, feel free to let me know! Well, hg bisect doesn't seem to be helping me find the answer. I fear that the real problem is in base64_decode, but for now I'm going to sleep instead of drowsily being confused by a debugger. -- Asheesh. -- QOTD: Some people have one of those days. I've had one of those lives.
Re: [Dovecot] assertion failed with KMail 3.5.6 and dovecot 1.0.0
On Mon, 2007-07-30 at 15:07 +0200, Sylvain Joyeux wrote: IMAP(doudou): file ostream-crlf.c: line 339 (_send_istream): assertion failed: ((size_t)ret = iov.iov_len) Hmm. Can you get Dovecot to dump a core file? Probably easiest way to get this fixed would be then if you sent me the core file and also the imap binary and I'll debug it further. Or I could also send you several gdb commands you could run. Here are the imap executable and core dump files (compressed). They are generated on a powerpc machine, so I'm not sure it will be useful to you. Moreover, Debian strips its executables, so no line numbers ... Debugging information would have been really useful, but I did fix one bug and added some more asserts: http://hg.dovecot.org/dovecot-1.0/rev/bd113e9fe67b If it still wasn't fixed, maybe with this change it gives another assert. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed with KMail 3.5.6 and dovecot 1.0.0
On 23.7.2007, at 11.25, Sylvain Joyeux wrote: Please CC me on answer, as I'm not subscribed on the list Here is the description of the problem. The system description follows. Everytime I read my email using KMail 3.5.6, dovecot hangs up near the end. I get the following in mail.err: IMAP(doudou): file ostream-crlf.c: line 339 (_send_istream): assertion failed: ((size_t)ret = iov.iov_len) Hmm. Can you get Dovecot to dump a core file? See http://dovecot.org/ bugreport.html Probably easiest way to get this fixed would be then if you sent me the core file and also the imap binary and I'll debug it further. Or I could also send you several gdb commands you could run. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Tue, 2007-07-17 at 22:34 +0200, Ralf Hildebrandt wrote: * Timo Sirainen [EMAIL PROTECTED]: On Tue, 2007-07-17 at 21:06 +0200, Ralf Hildebrandt wrote: I'm getting these in my log: Jul 17 11:40:42 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:40:42 postamt dovecot: child 26581 (login) killed with signal 6 Jul 17 11:51:12 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:51:12 postamt dovecot: child 24406 (login) killed with signal 6 This is dovecot-1.0.2 -- is this something to worry about? Do you see Disconnected: Connection queue full messages in your logs? Yes, at the very same times the other messages are appearing - from my logs: Jul 17 11:40:42 postamt dovecot: imap-login: Disconnected: Connection queue full: rip=192.168.232.149, lip=141.42.4.250 Jul 17 11:51:12 postamt dovecot: imap-login: Disconnected: Connection queue full: rip=193.175.70.61, lip=141.42.4.250 You might want to increase the number of simultaneous login processes if you're reaching this limit. http://wiki.dovecot.org/LoginProcess Of course it shouldn't crash either, I'll see if I can get that fixed. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Tue, 2007-07-17 at 21:06 +0200, Ralf Hildebrandt wrote: I'm getting these in my log: Jul 17 11:40:42 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:40:42 postamt dovecot: child 26581 (login) killed with signal 6 Jul 17 11:51:12 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:51:12 postamt dovecot: child 24406 (login) killed with signal 6 This is dovecot-1.0.2 -- is this something to worry about? Do you see Disconnected: Connection queue full messages in your logs? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
* Timo Sirainen [EMAIL PROTECTED]: On Tue, 2007-07-17 at 21:06 +0200, Ralf Hildebrandt wrote: I'm getting these in my log: Jul 17 11:40:42 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:40:42 postamt dovecot: child 26581 (login) killed with signal 6 Jul 17 11:51:12 postamt dovecot: imap-login: file ssl-proxy-openssl.c: line 460 (ssl_proxy_new): assertion failed: (fd != -1) Jul 17 11:51:12 postamt dovecot: child 24406 (login) killed with signal 6 This is dovecot-1.0.2 -- is this something to worry about? Do you see Disconnected: Connection queue full messages in your logs? Yes, at the very same times the other messages are appearing - from my logs: Jul 17 11:40:42 postamt dovecot: imap-login: Disconnected: Connection queue full: rip=192.168.232.149, lip=141.42.4.250 Jul 17 11:51:12 postamt dovecot: imap-login: Disconnected: Connection queue full: rip=193.175.70.61, lip=141.42.4.250 -- Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de How many viruses must arrive before people realize, that M$ is just not ready for the enterprise?
Re: [Dovecot] assertion failed
On Wed, 2007-05-09 at 15:44 +0200, Jan-Frode Myklebust wrote: On 2007-05-09, Timo Sirainen [EMAIL PROTECTED] wrote: Fixed it to log an error instead in such situations: http://dovecot.org/list/dovecot-cvs/2007-May/008728.html Great, thanks! We just moved a large cluster (100k+ active accounts) from courier pop/imap to dovecot (v1.0.0), and used the courier-dovecot-migrate.pl to do the conversion of maildirs. Was it courier-dovecot-migrate.pl then that created those broken uidlist files? I guess I should fix it too then. A couple of other failures we've been hitting is: deliver([EMAIL PROTECTED]): file mail-index-sync-update.c: line 841 (mail_index_sync_update_index): assertion failed: (view-hdr.messages_count == map-hdr.messages_count) .. deliver([EMAIL PROTECTED]): file mail-index.c: line 983 (mail_index_sync_from_transactions): assertion failed: (hdr.messages_count == (*map)-hdr.messages_count) I hoped these were completely fixed in v1.0. What filesystem do you use? deliver([EMAIL PROTECTED]): file maildir-save.c: line 520 (maildir_transaction_save_commit_pre): assertion failed: (first_uid != 0) Hopefully fixed by the above patch. Or I think this should happen only if next_uid=0 in the uidlist header. dovecot: POP3([EMAIL PROTECTED]): file maildir-sync.c: line 1075 (maildir_sync_index): assertion failed: (uid prev_uid) I haven't seen this one before. I'll try to figure out how it could happen. The deliver bugs are quite bad, as they lead to incoming messages getting bounced.. Those are all assertion failures. Doesn't your MTA treat deliver crashes as temporary failures which are retried? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Sun, May 13, 2007 at 08:50:16PM +0300, Timo Sirainen wrote: Was it courier-dovecot-migrate.pl then that created those broken uidlist files? Yes, we cleaned these up manually. deliver([EMAIL PROTECTED]): file mail-index-sync-update.c: line 841 (mail_index_sync_update_index): assertion failed: (view-hdr.messages_count == map-hdr.messages_count) .. deliver([EMAIL PROTECTED]): file mail-index.c: line 983 (mail_index_sync_from_transactions): assertion failed: (hdr.messages_count == (*map)-hdr.messages_count) I hoped these were completely fixed in v1.0. What filesystem do you use? IBM's GPFS on linux, which is a shared disk cluster fs. The deliver bugs are quite bad, as they lead to incoming messages getting bounced.. Those are all assertion failures. Doesn't your MTA treat deliver crashes as temporary failures which are retried? No, sorry.. postfix seems to be bouncing when deliver dies from signal 6.: postfix/pipe[21066]: 4D76F3B67E: to=[EMAIL PROTECTED], relay=dovecot, delay=0.3, delays=0/0/0/0.3, dsn=5.3.0, status=bounced (Command died with signal 6: /usr/local/dovecot/libexec/dovecot/deliver) I guess postfix doesn't really have any way of knowing how far the delivery succeeded, but I'd prefer if postfix would freeze these instead. -jf
Re: [Dovecot] assertion failed
On Sun, 2007-05-13 at 22:10 +0200, Jan-Frode Myklebust wrote:
On Sun, May 13, 2007 at 08:50:16PM +0300, Timo Sirainen wrote:
Was it courier-dovecot-migrate.pl then that created those broken uidlist
files?
Yes, we cleaned these up manually.
OK, updated the script so other people won't run into the same problem.
deliver([EMAIL PROTECTED]): file mail-index-sync-update.c: line 841
(mail_index_sync_update_index): assertion failed:
(view-hdr.messages_count == map-hdr.messages_count)
..
deliver([EMAIL PROTECTED]): file mail-index.c: line 983
(mail_index_sync_from_transactions): assertion failed:
(hdr.messages_count == (*map)-hdr.messages_count)
I hoped these were completely fixed in v1.0. What filesystem do you use?
IBM's GPFS on linux, which is a shared disk cluster fs.
So either there's some problem that only occurs with GPFS or it adds
enough latency that a race condition somewhere can cause problems.
Before v1.0 release I was running imap stress testing for many hours
(reading and modifying the same mailbox) without a single error, so I
doubt I can reproduce this myself. And if I can't reproduce it, this is
going to be pretty much impossible to fix.
For Dovecot v1.1 I'm going to simplify the index file code so at least
then this error should hopefully go away.
Those are all assertion failures. Doesn't your MTA treat deliver crashes
as temporary failures which are retried?
No, sorry.. postfix seems to be bouncing when deliver dies from signal
6.:
So it seems. If you're using syslog, you could use the attached patch.
But maybe this should be changed in Postfix side? I guess I could try
asking in Postfix list if they've something against it. You could anyway
change that by modifying src/global/pipe_command.c around line 630:
if (WIFSIGNALED(wait_status)) {
dsb_unix(why, 5.3.0, log_len ?
Change 5.3.0 to 4.3.0
? src/deliver/foo
? src/deliver/log
Index: src/deliver/deliver.c
===
RCS file: /var/lib/cvs/dovecot/src/deliver/deliver.c,v
retrieving revision 1.20.2.39
diff -u -r1.20.2.39 deliver.c
--- src/deliver/deliver.c 13 May 2007 14:06:19 - 1.20.2.39
+++ src/deliver/deliver.c 13 May 2007 20:33:34 -
@@ -426,6 +426,11 @@
}
}
+static void deliver_syslog_panic_handler(const char *fmt, va_list args)
+{
+ i_syslog_fatal_handler(EX_TEMPFAIL, fmt, args);
+}
+
static void open_logfile(const char *username)
{
const char *prefix, *log_path, *stamp;
@@ -439,6 +444,7 @@
if (env == NULL || !syslog_facility_find(env, facility))
facility = LOG_MAIL;
i_set_failure_syslog(prefix, LOG_NDELAY, facility);
+ i_set_panic_handler(deliver_syslog_panic_handler);
} else {
/* log to file or stderr */
i_set_failure_file(log_path, t_strconcat(prefix, : , NULL));
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Sun, May 13, 2007 at 11:40:12PM +0300, Timo Sirainen wrote: IBM's GPFS on linux, which is a shared disk cluster fs. So either there's some problem that only occurs with GPFS or it adds enough latency that a race condition somewhere can cause problems. Before v1.0 release I was running imap stress testing for many hours (reading and modifying the same mailbox) without a single error, so I doubt I can reproduce this myself. And if I can't reproduce it, this is going to be pretty much impossible to fix. For Dovecot v1.1 I'm going to simplify the index file code so at least then this error should hopefully go away. Any idea when v1.1 will be released ? The mail_index_sync_update_index failure is happening about once a day, so we need to get something done about it.. Hmmm, maybe setting the postfix soft_bounce=yes (as suggested by Jasper Slits) will be an acceptable workaround for us, as I don't think these servers should ever need to bounce mail (other servers in front of them should be handeling that). -jf
Re: [Dovecot] assertion failed
On Sun, 2007-05-13 at 22:53 +0200, Jan-Frode Myklebust wrote: For Dovecot v1.1 I'm going to simplify the index file code so at least then this error should hopefully go away. Any idea when v1.1 will be released ? I haven't even started doing the index code cleanups. But I did write a small summary about it: http://dovecot.org/list/dovecot/2007-May/022591.html I'm anyway hoping that I can get v1.1 mostly (if not completely) ready this summer. Unless I suddenly start wasting a lot of time with other things (such as paying work). signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Mon, May 14, 2007 at 12:20:43AM +0300, Timo Sirainen wrote: I haven't even started doing the index code cleanups. But I did write a small summary about it: http://dovecot.org/list/dovecot/2007-May/022591.html Which got me thinking.. Do you think changing locking method might help with these assertion failures ? Currently we're using default lock_method, but maybe one of the others are more appropriate for shared file-systems ? ... maybe even just to change code paths if this is a race we're seeing. Any thoughts ? -jf
Re: [Dovecot] assertion failed
On Sun, 2007-05-13 at 23:46 +0200, Jan-Frode Myklebust wrote: On Mon, May 14, 2007 at 12:20:43AM +0300, Timo Sirainen wrote: I haven't even started doing the index code cleanups. But I did write a small summary about it: http://dovecot.org/list/dovecot/2007-May/022591.html Which got me thinking.. Do you think changing locking method might help with these assertion failures ? Currently we're using default lock_method, but maybe one of the others are more appropriate for shared file-systems ? ... maybe even just to change code paths if this is a race we're seeing. Any thoughts ? Code paths between fcntl and flock are pretty much the same. Unless there's a bug in GPFS it shouldn't make a difference which one you use. You can always try of course. Changing to dotlock would make it use a bit different code paths, but it also would make it slower. The biggest difference is between mmap_disable=yes and =no, but unless GPFS supports shared mmaps it's probably not a good idea to set that to no. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Sun, 2007-05-13 at 23:46 +0200, Jan-Frode Myklebust wrote: On Mon, May 14, 2007 at 12:20:43AM +0300, Timo Sirainen wrote: I haven't even started doing the index code cleanups. But I did write a small summary about it: http://dovecot.org/list/dovecot/2007-May/022591.html Which got me thinking.. Do you think changing locking method might help with these assertion failures ? Currently we're using default lock_method, but maybe one of the others are more appropriate for shared file-systems ? ... maybe even just to change code paths if this is a race we're seeing. Any thoughts ? One possibility of course is to just disable index file updates completely with deliver. Those crashes were all related to index file handling. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On Wed, 2007-05-02 at 14:10 +0200, Jan-Frode Myklebust wrote: On 2007-04-26, Adrian Stoica [EMAIL PROTECTED] wrote: What is this ? We just saw the same fault today when we switched from courier to dovecot on a large system today. The ~username/dovecot-uidlist contained: 1 -1 0 and deleting this file plus it's lockfile seems to have fixed the problem for the two users this happened for. Fixed it to log an error instead in such situations: http://dovecot.org/list/dovecot-cvs/2007-May/008728.html signature.asc Description: This is a digitally signed message part
Re: [Dovecot] assertion failed
On 2007-05-09, Timo Sirainen [EMAIL PROTECTED] wrote: Fixed it to log an error instead in such situations: http://dovecot.org/list/dovecot-cvs/2007-May/008728.html Great, thanks! We just moved a large cluster (100k+ active accounts) from courier pop/imap to dovecot (v1.0.0), and used the courier-dovecot-migrate.pl to do the conversion of maildirs. A couple of other failures we've been hitting is: #1: deliver([EMAIL PROTECTED]): file mail-index-sync-update.c: line 841 (mail_index_sync_update_index): assertion failed: (view-hdr.messages_count == map-hdr.messages_count) deliver([EMAIL PROTECTED]): Raw backtrace: /usr/local/dovecot/libexec/dovecot/deliver(i_syslog_panic_handler+0x1c) [0x45d67c] - /usr/local/dovecot/libexec/dovecot/deliver [0x45d27c] - /usr/local/dovecot/libexec/dovecot/deliver(mail_index_sync_update_index+0x86f) [0x446abf] - /usr/local/dovecot/libexec/dovecot/deliver(mail_index_sync_begin+0x245) [0x444665] - /usr/local/dovecot/libexec/dovecot/deliver(maildir_sync_index_begin+0x45) [0x416885] - /usr/local/dovecot/libexec/dovecot/deliver(maildir_transaction_save_commit_pre+0x68) [0x41c778] - /usr/local/dovecot/libexec/dovecot/deliver(maildir_transaction_commit+0x70) [0x417730] - /usr/local/dovecot-1.0.0/lib/dovecot/lda/lib10_quota_plugin.so [0x2a9557c3a8] - /usr/local/dovecot/libexec/dovecot/deliver(deliver_save+0x100) [0x411360] - /usr/local/dovecot/libexec/dovecot/deliver(main+0xb62) [0x412132] - /lib64/tls/libc.so.6(__libc_start_main+0xdb) [0x307b11c3fb] - /usr/local/dovecot/libexec/dovecot/deliver [0x410b0a] #2: deliver([EMAIL PROTECTED]): file mail-index.c: line 983 (mail_index_sync_from_transactions): assertion failed: (hdr.messages_count == (*map)-hdr.messages_count) deliver([EMAIL PROTECTED]): Raw backtrace: /usr/local/dovecot/libexec/dovecot/deliver(i_syslog_panic_handler+0x1c) [0x45d67c] - /usr/local/dovecot/libexec/dovecot/deliver [0x45d27c] - /usr/local/dovecot/libexec/dovecot/deliver(mail_index_map+0x87) [0x43e5f7] - /usr/local/dovecot/libexec/dovecot/deliver(mail_index_sync_begin+0x9e) [0xbe] - /usr/local/dovecot/libexec/dovecot/deliver(maildir_sync_index_begin+0x45) [0x416885] - /usr/local/dovecot/libexec/dovecot/deliver [0x4173aa] - /usr/local/dovecot/libexec/dovecot/deliver(maildir_sync_last_commit+0x47) [0x4174c7] - /usr/local/dovecot-1.0.0/lib/dovecot/lda/lib10_quota_plugin.so [0x2a9557c3a8] - /usr/local/dovecot/libexec/dovecot/deliver(deliver_save+0x100) [0x411360] - /usr/local/dovecot/libexec/dovecot/deliver(main+0xb62) [0x412132] - /lib64/tls/libc.so.6(__libc_start_main+0xdb) [0x307b11c3fb] - /usr/local/dovecot/libexec/dovecot/deliver [0x410b0a] #3: deliver([EMAIL PROTECTED]): file maildir-save.c: line 520 (maildir_transaction_save_commit_pre): assertion failed: (first_uid != 0) deliver([EMAIL PROTECTED]): Raw backtrace: /usr/local/dovecot/libexec/dovecot/deliver(i_syslog_panic_handler+0x1c) [0x45d67c] - /usr/local/dovecot/libexec/dovecot/deliver [0x45d27c] - /usr/local/dovecot/libexec/dovecot/deliver [0x41c9ed] - /usr/local/dovecot/libexec/dovecot/deliver(maildir_transaction_commit+0x70) [0x417730] - /usr/local/dovecot-1.0.0/lib/dovecot/lda/lib10_quota_plugin.so [0x2a9557c3a8] - /usr/local/dovecot/libexec/dovecot/deliver(deliver_save+0x100) [0x411360] - /usr/local/dovecot/libexec/dovecot/deliver(main+0xb62) [0x412132] - /lib64/tls/libc.so.6(__libc_start_main+0xdb) [0x307b11c3fb] - /usr/local/dovecot/libexec/dovecot/deliver [0x410b0a] #4: dovecot: POP3([EMAIL PROTECTED]): file maildir-sync.c: line 1075 (maildir_sync_index): assertion failed: (uid prev_uid) dovecot: POP3([EMAIL PROTECTED]): Raw backtrace: /usr/local/dovecot/libexec/dovecot/pop3 [0x45d73c] - /usr/local/dovecot/libexec/dovecot/pop3 [0x45d03c] - /usr/local/dovecot/libexec/dovecot/pop3(maildir_sync_index+0x769) [0x417029] - /usr/local/dovecot/libexec/dovecot/pop3 [0x417171] - /usr/local/dovecot/libexec/dovecot/pop3(maildir_storage_sync_init+0x65) [0x4173c5] - /usr/local/dovecot/libexec/dovecot/pop3(client_create+0x15d) [0x4111dd] - /usr/local/dovecot/libexec/dovecot/pop3(main+0x554) [0x412fd4] - /lib64/tls/libc.so.6(__libc_start_main+0xdb) [0x389e61c3fb] - /usr/local/dovecot/libexec/dovecot/pop3 [0x410a2a] The deliver bugs are quite bad, as they lead to incoming messages getting bounced.. -jf
Re: [Dovecot] assertion failed
On 2007-04-26, Adrian Stoica [EMAIL PROTECTED] wrote: What is this ? We just saw the same fault today when we switched from courier to dovecot on a large system today. The ~username/dovecot-uidlist contained: 1 -1 0 and deleting this file plus it's lockfile seems to have fixed the problem for the two users this happened for. -jf
Re: [Dovecot] assertion failed (1.0-rc27)
On Wed, Mar 28, 2007 at 10:24:40PM +0300, Timo Sirainen wrote: On 28.3.2007, at 22.13, Steven F Siirila wrote: Under Dovecot 1.0-rc27 on Solaris 10 we noticed this error today affecting one of our users repeatedly: Mar 28 14:02:01 myhost dovecot: IMAP(myuser): file mbox-sync- rewrite.c: line 423 (mbox_sync_read_and_move): assertion failed: (need_space == (uoff_t)-mails[idx].space) In rc28 I've changed this assert to something that prints more useful information. This assert alone doesn't really tell anything what the problem could have been. Anyway if it happened repeatedly, it would be nice to get the anonymized mbox and index files. See http://wiki.dovecot.org/ MboxProblems I have reproduced this on a test box; here is the backtrace from the core that was generated: #0 0xff1c16e8 in _sys_siginfolist_data () from /lib/libc.so.1 #1 0xff15ff40 in __strxfrm_std () from /lib/libc.so.1 #2 0xff140160 in getutxline () from /lib/libc.so.1 #3 0x0007b1b8 in i_internal_panic_handler ( fmt=0x929c8 file %s: line %d (%s): assertion failed: (%s), args=0xffbfec98) at failures.c:403 #4 0x0007ac5c in i_panic ( format=0x929c8 file %s: line %d (%s): assertion failed: (%s)) at failures.c:183 #5 0x00042cdc in mbox_sync_rewrite (sync_ctx=0xffbff3f8, mail_ctx=0x92800, end_offset=13387, move_diff=40611, extra_space=4295021294, first_seq=1, last_seq=163) at mbox-sync-rewrite.c:579 #6 0x0003e970 in mbox_sync_do (sync_ctx=0xffbff3f8, flags=4290769568) at mbox-sync.c:1332 #7 0x0003f554 in mbox_sync (mbox=0xc1c48, flags=MBOX_SYNC_UNDIRTY) at mbox-sync.c:1800 #8 0x0003f988 in mbox_storage_sync_init (box=0xc1c48, flags=MAILBOX_SYNC_FLAG_FULL_READ) at mbox-sync.c:1869 #9 0x0006c83c in mailbox_sync_init (box=0xc1c48, flags=MAILBOX_SYNC_FLAG_FULL_READ) at mail-storage.c:406 #10 0x000298a8 in imap_sync_nonselected (box=0xc1c48, flags=MAILBOX_SYNC_FLAG_FULL_READ) at imap-sync.c:196 #11 0x00021154 in _cmd_select_full (cmd=0xbbd7c, readonly=false) at cmd-select.c:39 #12 0x000212f0 in cmd_select (cmd=0xbbd7c) at cmd-select.c:92 #13 0x00022d68 in client_handle_input (cmd=0xbbd7c) at client.c:332 #14 0x00022ce0 in client_handle_input (cmd=0xbbd7c) at client.c:389 #15 0x00022ee0 in _client_input (context=0xbbd38) at client.c:432 #16 0x0008100c in io_loop_handler_run (ioloop=0xb9530) at ioloop-poll.c:199 #17 0x000808c8 in io_loop_run (ioloop=0xb9530) at ioloop.c:323 #18 0x0002b400 in main (argc=-4195374, argv=0xaf800, envp=0xb0be4) at main.c:287 I still have the core, in case there is other information from gdb that would be useful in diagnosing this. -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: [EMAIL PROTECTED] Office of Information TechnologyVoice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593
Re: [Dovecot] assertion failed (1.0-rc27)
On 29.3.2007, at 1.10, Steven F Siirila wrote: Anyway if it happened repeatedly, it would be nice to get the anonymized mbox and index files. See http://wiki.dovecot.org/ MboxProblems I have reproduced this on a test box; here is the backtrace from the core that was generated: Can you reproduce this multiple times? If so, I'd really like the mbox file (anonymized) and the index files. It's much easier to fix the problem if I can reproduce it myself. I still have the core, in case there is other information from gdb that would be useful in diagnosing this. At least: fr 5 p *mail_ctx p *sync_ctx p mails[idx] PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] assertion failed (1.0-rc27)
On Thu, Mar 29, 2007 at 01:38:59AM +0300, Timo Sirainen wrote:
On 29.3.2007, at 1.10, Steven F Siirila wrote:
Anyway if it happened repeatedly, it would be nice to get the
anonymized mbox and index files. See http://wiki.dovecot.org/
MboxProblems
I have reproduced this on a test box; here is the backtrace from
the core
that was generated:
Can you reproduce this multiple times? If so, I'd really like the
mbox file (anonymized) and the index files. It's much easier to fix
the problem if I can reproduce it myself.
I'll see what I can put together; however, let me know if the
information below turns out to be sufficient...
I still have the core, in case there is other information from gdb
that
would be useful in diagnosing this.
At least:
fr 5
#5 0x00042cdc in mbox_sync_rewrite (sync_ctx=0xffbff3f8, mail_ctx=0x92800,
end_offset=13387, move_diff=40611, extra_space=4295021294, first_seq=1,
last_seq=163) at mbox-sync-rewrite.c:579
579 i_assert(move_diff + (off_t)expunged_space = 0);
p *mail_ctx
$1 = {sync_ctx = 0x5f676574, mail = {uid = 2036297574, idx_seq = 1718838644,
keywords = {buffer = 0x0, element_size = 0}, flags = 114 'r',
uid_broken = 0 '\0', expunged = 1 '\001', pseudo = 1 '\001',
from_offset = 4495277855392886630, body_size = 7382355763620035872,
offset = 2915358819387143209, space = 3256384005565579264},
seq = 1769174130, hdr_offset = 824244805484408,
body_offset = 6874574906695249764, header_first_change = 2036298601,
header_last_change = 2053439488, header = 0x72737472,
hdr_md5_sum = eam-hdr_offset , content_length = 8462094814726596909,
hdr_pos = {822083584, 0, 1920169074, 1700883757, 1047355753},
parsed_uid = 1818194793, last_uid_updated_value = 2053447713,
last_uid_value_start_pos = 1025517685, have_eoh = 0, need_rewrite = 1,
seen_imapbase = 1, updated = 0, recent = 1, dirty = 1, imapbase_rewrite = 1,
imapbase_updated = 1}
p *sync_ctx
$2 = {mbox = 0xc1c48, flags = MBOX_SYNC_UNDIRTY, input = 0xc6bd0,
file_input = 0xc6ab0, write_fd = 8, orig_mtime = 1175119566,
orig_size = 36478386, index_sync_ctx = 0xc30b8, sync_view = 0xc30f0,
t = 0xc46a0, hdr = 0xc3138, header = 0xba6a0, from_line = 0xba678,
base_uid_validity = 1155907017, base_uid_last = 9356,
base_uid_last_offset = 0, mails = {buffer = 0xba6c8, element_size = 56},
syncs = {buffer = 0xba6f0, element_size = 20}, sync_rec = {uid1 = 0,
uid2 = 0, type = 0, add_flags = 0 '\0', remove_flags = 0 '\0',
keyword_idx = 0}, mail_keyword_pool = 0xc48f8,
saved_keywords_pool = 0xc4a00, prev_msg_uid = 9356, next_uid = 10170,
idx_next_uid = 1, seq = 813, idx_seq = 814, need_space_seq = 1,
expunged_space = 0, space_diff = -40662, dest_first_mail = 1,
first_mail_crlf_expunged = 0, delay_writes = 0, renumber_uids = 0,
moved_offsets = 0}
p mails[idx]
$3 = {uid = 9357, idx_seq = 1, keywords = {buffer = 0x0, element_size = 0},
flags = 8 '\b', uid_broken = 0 '\0', expunged = 0 '\0', pseudo = 0 '\0',
from_offset = 0, body_size = 11844, offset = 50, space = -11}
--
Steven F. Siirila Office: Lind Hall, Room 130B
Internet Services E-mail: [EMAIL PROTECTED]
Office of Information TechnologyVoice: (612) 626-0244
University of Minnesota Fax: (612) 626-7593
