[Dovecot] dovecot-1.1.rc3 segmentation fault in fetch_bodystructure
Hi, another imap crash with latest dovecot.
segmentation fault in fetch_bodystructure
src/imap/imap-fetch.c static int fetch_bodystructure(struct imap_fetch_context *ctx, struct mail *mail, void *context ATTR_UNUSED) { const char *bodystructure;
if (mail_get_special(mail, MAIL_FETCH_IMAP_BODYSTRUCTURE,
&bodystructure) < 0)
return -1;---> before the segfault here we have bodystructure=0 and mail_get_special returns >=0 [..]
if (o_stream_send(ctx->client->output, "BODYSTRUCTURE (", 15) < 0 ||/*line 461*/ o_stream_send_str(ctx->client->output, bodystructure) < 0 ||
---> here o_stream_send_str calls strlen(bodystructure=0), and strlen tries to access "Address 0x0" causing a segfault
-- Address 0x0 is not stack'd, malloc'd or (recently) free'd Process terminating with default action of signal 11 (SIGSEGV): dumping core Access not within mapped region at address 0x0 at: strlen by: o_stream_send_str (ostream.c:163) by: fetch_bodystructure (imap-fetch.c:461) by: imap_fetch (imap-fetch.c:309) by: cmd_fetch (cmd-fetch.c:154) by: client_command_input (client.c:546) by: client_command_input (client.c:595) by: client_handle_input (client.c:636) by: client_input (client.c:691) by: io_loop_handler_run (ioloop-epoll.c:201) by: io_loop_run (ioloop.c:301) by: main (main.c:293)
On Tue, 2008-03-11 at 08:54 +0100, Diego Liziero wrote:
Hi, another imap crash with latest dovecot.
segmentation fault in fetch_bodystructure
Well, I'm not sure how you managed to cause this, but this should fix it: http://hg.dovecot.org/dovecot-1.1/rev/7e27d67d3abe
On Tue, Mar 11, 2008 at 9:09 AM, Timo Sirainen <tss@iki.fi> wrote:
Well, I'm not sure how you managed to cause this, but this should fix it: http://hg.dovecot.org/dovecot-1.1/rev/7e27d67d3abe
Thank you Timo for the quick fix, here we have latest rc3 in a production environment. It has been used by over 600 users in the last 2 days.
The most failing assertion (9694 times in 2 days) is the one I posted yesterday: Panic: IMAP(username): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
It happens when users are moving messages to Trash folder with thunderbird. The workaround for the user is to delete directly the messages without moving them to Trash.
We had also some trouble with pop3. A couple of users weren't able to get new mail (see log below) until we deleted completely their .imap dir.
Diego.
Error: POP3(username): Cached message offset lost for seq 1 in mbox file /maildir/username Error: POP3(username): Log synchronization error at seq=1,offset=7824 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field alignmentation 8 not used Error: POP3(username): Log synchronization error at seq=1,offset=7856 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field points outside record size (0+16 > 12) Error: POP3(username): Log synchronization error at seq=1,offset=7928 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field alignmentation 8 not used Error: POP3(username): Log synchronization error at seq=1,offset=8004 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field points outside record size (0+16 > 12) Warning: POP3(username): fscking index file /maildir/username/.imap/INBOX/dovecot.index Error: POP3(username): Cached message offset lost for seq 1 in mbox file /cl/e/spool-mail/username Error: POP3(username): Log synchronization error at seq=1,offset=8208 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field alignmentation 8 not used Error: POP3(username): Log synchronization error at seq=1,offset=8240 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field points outside record size (0+16 > 12) Error: POP3(username): Log synchronization error at seq=1,offset=8312 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field alignmentation 8 not used Error: POP3(username): Log synchronization error at seq=1,offset=8388 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field points outside record size (0+16 > 12) Warning: POP3(username): fscking index file /maildir/username/.imap/INBOX/dovecot.index Error: POP3(username): Sending log messages too fast, throttling.. Error: POP3(username): Couldn't init INBOX: Can't sync mailbox: Messages keep getting expunged
On Tue, 2008-03-11 at 09:55 +0100, Diego Liziero wrote:
The most failing assertion (9694 times in 2 days) is the one I posted yesterday: Panic: IMAP(username): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
It happens when users are moving messages to Trash folder with thunderbird. The workaround for the user is to delete directly the messages without moving them to Trash.
You mean it's reproducible easily? I tried to reproduce it myself today but wasn't able to.
The problem is that Dovecot tries to mark a message \Recent in the middle of mailbox, but only new messages at the end of the mailbox can become \Recent, so it crashes.
Do your users have direct access to mboxes?
We had also some trouble with pop3. A couple of users weren't able to get new mail (see log below) until we deleted completely their .imap dir.
Error: POP3(username): Cached message offset lost for seq 1 in mbox file /maildir/username Error: POP3(username): Log synchronization error at seq=1,offset=7824 for /maildir/username/.imap/INBOX/dovecot.index: Broken extension introduction: Record field alignmentation 8 not used
If you get this again and the problem doesn't get fixed by itself, I'd like to get the dovecot.index and dovecot.index.log files to see if I could reproduce it and get it to fix itself. Those files don't contain anything sensitive about the mail contents.
But as for why this corruption happens in the first place.. What OS and filesystem do you use?
On Tue, Mar 11, 2008 at 09:55:02AM +0100, Diego Liziero wrote:
On Tue, Mar 11, 2008 at 9:09 AM, Timo Sirainen <tss@iki.fi> wrote:
Well, I'm not sure how you managed to cause this, but this should fix it: http://hg.dovecot.org/dovecot-1.1/rev/7e27d67d3abe
Thank you Timo for the quick fix, here we have latest rc3 in a production environment. It has been used by over 600 users in the last 2 days.
The most failing assertion (9694 times in 2 days) is the one I posted yesterday: Panic: IMAP(username): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
It happens when users are moving messages to Trash folder with thunderbird. The workaround for the user is to delete directly the messages without moving them to Trash.
Today, we received several complaints about being unable to delete messages (by moving to Trash) not working, and discovered we were getting the same assertion failure as you:
assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
The only client being used was Squirrelmail with no external access from any other client.
Can you confirm that the patch Timo submited in the above link fixes this problem for 1.1rc3? If so, will this be committed for rc4 or beyond?
-- Dean Brooks dean@iglou.com
On Thu, 2008-03-27 at 12:47 -0400, Dean Brooks wrote:
On Tue, Mar 11, 2008 at 09:55:02AM +0100, Diego Liziero wrote:
On Tue, Mar 11, 2008 at 9:09 AM, Timo Sirainen <tss@iki.fi> wrote:
Well, I'm not sure how you managed to cause this, but this should fix it: http://hg.dovecot.org/dovecot-1.1/rev/7e27d67d3abe
Today, we received several complaints about being unable to delete messages (by moving to Trash) not working, and discovered we were getting the same assertion failure as you:
assertion failed: (seq_range_exists(&ibox->recent_flags, uid))
The only client being used was Squirrelmail with no external access from any other client.
Can you confirm that the patch Timo submited in the above link fixes this problem for 1.1rc3? If so, will this be committed for rc4 or beyond?
The patch will be in rc4, but it's for a completely different problem. Easiest way to get rid of this problem for now is to just comment out the assert, but it would be nice if you could figure out a way to reproduce this so I could properly fix it.
On Thu, Mar 27, 2008 at 5:47 PM, Dean Brooks <dean@iglou.com> wrote:
Can you confirm that the patch Timo submited in the above link fixes this problem for 1.1rc3? If so, will this be committed for rc4 or beyond?
No, the above patch was about another issue (segmentation fault in fetch_bodystructure) and I forgot to change the subject about the assertion failure you are getting. As Timo told you, I changed the assert with a i_error waiting for a proper fix. Diego. --- ./src/lib-storage/index/index-sync.c-orig 2008-03-13 16:46: 36.000000000 +0100 +++ ./src/lib-storage/index/index-sync.c 2008-03-13 16:51: 38.000000000 +0100 @@ -36,7 +36,9 @@ void index_mailbox_set_recent_uid(struct index_mailbox *ibox, uint32_t uid) { if (uid <= ibox->recent_flags_prev_uid) { - i_assert(seq_range_exists(&ibox->recent_flags, uid)); + /*i_assert(seq_range_exists(&ibox->recent_flags, uid));*/ + if (!seq_range_exists(&ibox->recent_flags, uid)) + i_error("seq_range_exists(&ibox->recent_flags, uid)"); return; } ibox->recent_flags_prev_uid = uid;
participants (3)
-
Dean Brooks
-
Diego Liziero
-
Timo Sirainen