Re: [Dovecot] Dovecot 1.2.6 segfault in imap_fetch_begin
On Thu, 2009-10-15 at 18:05 -0400, Timo Sirainen wrote: > On Thu, 2009-10-15 at 13:06 -0700, Brandon Davidson wrote: > > Yes, we've got a pool of servers with Maildir on NFS with quotas > > enabled. Occasionally the users will run out of space and the indexes > > will get corrupted or out of sync. Our Helpdesk staff will increase > > their quota or help them delete things, and Dovecot logs a stream of " > > Expunged message reappeared" and "Duplicate file entry" messages as it > > straightens things out. This is a fairly common occurrence given the > > size of our user base, so I'm assuming this is the root cause... but > > this is the first time I've seen Dovecot crash as a result. > > Well, none of that should be happening.. Oh, actually, that's about dovecot-uidlist files. They don't like much if writing fails. Although I'm still not sure if those types of errors should be happening.. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot 1.2.6 segfault in imap_fetch_begin
On Thu, 2009-10-15 at 13:06 -0700, Brandon Davidson wrote: > Yes, we've got a pool of servers with Maildir on NFS with quotas > enabled. Occasionally the users will run out of space and the indexes > will get corrupted or out of sync. Our Helpdesk staff will increase > their quota or help them delete things, and Dovecot logs a stream of " > Expunged message reappeared" and "Duplicate file entry" messages as it > straightens things out. This is a fairly common occurrence given the > size of our user base, so I'm assuming this is the root cause... but > this is the first time I've seen Dovecot crash as a result. Well, none of that should be happening.. I guess I'll try some day again how random write failures to indexes will behave and if I can reproduce any of this. I last tried that with v1.0 or v1.1 and fixed all the related bugs. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot 1.2.6 segfault in imap_fetch_begin
Hi Timo, > -Original Message- > From: Timo Sirainen [mailto:t...@iki.fi] > > This just shouldn't be happening. Are you using NFS? Anyway this should > replace the crash with a nicer error message: > http://hg.dovecot.org/dovecot-1.2/rev/6c6460531514 Yes, we've got a pool of servers with Maildir on NFS with quotas enabled. Occasionally the users will run out of space and the indexes will get corrupted or out of sync. Our Helpdesk staff will increase their quota or help them delete things, and Dovecot logs a stream of " Expunged message reappeared" and "Duplicate file entry" messages as it straightens things out. This is a fairly common occurrence given the size of our user base, so I'm assuming this is the root cause... but this is the first time I've seen Dovecot crash as a result. -Brad
Re: [Dovecot] Dovecot 1.2.6 segfault in imap_fetch_begin
On Wed, 2009-10-14 at 17:51 -0700, Brandon Davidson wrote: > Thanks! As always, you're one step ahead of us with the bug fixes! I've > got one more for you that just popped up. I'm guessing that it's also > due to expunging causing sequence numbers to mixed up, and one of the > existing patches will fix it? No, not really. > The error from the logs is: > Panic: file mail-transaction-log-view.c: line 108 > (mail_transaction_log_view_set): assertion failed: (min_file_seq <= > max_file_seq) This just shouldn't be happening. Are you using NFS? Anyway this should replace the crash with a nicer error message: http://hg.dovecot.org/dovecot-1.2/rev/6c6460531514 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot 1.2.6 segfault in imap_fetch_begin
Timo, > -Original Message- > -O2 compiling has dropped one stage from the backtrace, but I think this > will fix the crash: > > I guess it would be time for 1.2.7 somewhat soon.. Thanks! As always, you're one step ahead of us with the bug fixes! I've got one more for you that just popped up. I'm guessing that it's also due to expunging causing sequence numbers to mixed up, and one of the existing patches will fix it? The error from the logs is: Panic: file mail-transaction-log-view.c: line 108 (mail_transaction_log_view_set): assertion failed: (min_file_seq <= max_file_seq) Raw backtrace: imap [0x49e4a0] -> imap [0x49e503] -> imap [0x49db66] -> imap(mail_transaction_log_view_set+0x4ac) [0x48651c] -> imap(mail_index_view_sync_begin+0xe5) [0x480055] -> imap(index_mailbox_sync_init+0x7f) [0x45e84f] -> imap(maildir_storage_sync_init+0x100) [0x43cd30] -> imap(imap_sync_init+0x67) [0x428257] -> imap(cmd_sync_delayed+0x174) [0x4284a4] -> imap(client_handle_input+0x19e) [0x420aee] -> imap(client_input+0x5f) [0x4214df] -> imap(io_loop_handler_run+0xf8) [0x4a61f8] -> imap(io_loop_run+0x1d) [0x4a530d] -> imap(main+0x620) [0x428da0] -> /lib64/libc.so.6(__libc_start_main+0xf4) [0x31d5a1d994] -> imap [0x419a89] dovecot: child 11758 (imap) killed with signal 6 (core dumped) Backtrace and such here: http://uoregon.edu/~brandond/dovecot-1.2.6/bt2.txt Thanks again, -Brad
Re: [Dovecot] Dovecot 1.2.6 segfault in imap_fetch_begin
On Wed, 2009-10-14 at 17:14 -0700, Brandon Davidson wrote: > Backtraces and some further information are available here. Cores > available on request. > http://uoregon.edu/~brandond/dovecot-1.2.6/bt.txt -O2 compiling has dropped one stage from the backtrace, but I think this will fix the crash: http://hg.dovecot.org/dovecot-1.2/rev/352eab3d6ade There are also a few other bugs in QRESYNC handling that get fixed by these: http://hg.dovecot.org/dovecot-1.2/rev/f7f0bff8438a http://hg.dovecot.org/dovecot-1.2/rev/51329696ecf5 http://hg.dovecot.org/dovecot-1.2/rev/73c4a7d325fe I guess it would be time for 1.2.7 somewhat soon.. signature.asc Description: This is a digitally signed message part
[Dovecot] Dovecot 1.2.6 segfault in imap_fetch_begin
We recently upgraded from Dovecot 1.2.4 to 1.2.6 (with the sieve patches of course). Everything has been running quite well since the upgrade. The occasional issue with assert-crashing when expunging has gone away. However, one of our users seems to have triggered a new issue. She's been the only one to see it, but whenever she logs in, her imap process segfaults immediately. It appears that the crash is a null pointer deref in the array library, but I'm not sure what code is at fault for calling in without checking array validity... or even if I'm on the right track. Backtraces and some further information are available here. Cores available on request. http://uoregon.edu/~brandond/dovecot-1.2.6/bt.txt Thanks, -Brad
