[Dovecot] 1.2.13 QRESYNC crash.
Aug 18 22:07:31 twosheds IMAP(dwmw2): : Panic: file mail-index-transaction.c: line 637 (mail_index_transaction_lookup): assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
- PREAUTH [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in as dwmw2 0 enable condstore qresync
- ENABLED CONDSTORE QRESYNC 0 OK Enabled. A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 1:* (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757)))
Program received signal SIGABRT, Aborted. 0x00000034ace326c5 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-9.fc12.x86_64 glibc-2.11.2-1.x86_64 keyutils-libs-1.2-6.fc12.x86_64 krb5-libs-1.7.1-9.fc12.x86_64 libcom_err-1.41.9-8.fc12.x86_64 libgcc-4.4.4-10.fc12.x86_64 libselinux-2.0.90-5.fc12.x86_64 nss-softokn-freebl-3.12.6-2.fc12.1.x86_64 openldap-2.4.19-4.fc12.x86_64 openssl-1.0.0a-1.fc12.x86_64 zlib-1.2.3-23.fc12.x86_64 (gdb) bt #0 0x00000034ace326c5 in raise () from /lib64/libc.so.6 #1 0x00000034ace33ea5 in abort () from /lib64/libc.so.6 #2 0x00000000004a2698 in default_fatal_finish (type=<value optimized out>, status=0) at failures.c:160 #3 0x00000000004a273b in i_syslog_fatal_handler (type=LOG_TYPE_PANIC, status=0, fmt=<value optimized out>, args=<value optimized out>) at failures.c:315 #4 0x00000000004a1d86 in i_panic (format=0x6 <Address 0x6 out of bounds>) at failures.c:207 #5 0x00000000004787f0 in mail_index_transaction_lookup ( t=<value optimized out>, seq=<value optimized out>) at mail-index-transaction.c:637 #6 0x000000000047be45 in tview_lookup_uid (view=<value optimized out>, seq=<value optimized out>, uid_r=<value optimized out>) at mail-index-transaction-view.c:162 #7 0x00000000004580fb in index_mail_set_seq (_mail=0x7282b8, seq=1578) at index-mail.c:1229 #8 0x0000000000423eb4 in expunges_drop_known (ctx=0x70a628) at imap-fetch.c:178 #9 get_expunges_fallback (ctx=0x70a628) at imap-fetch.c:269 #10 imap_fetch_send_vanished (ctx=0x70a628) at imap-fetch.c:291 #11 imap_fetch_begin (ctx=0x70a628) at imap-fetch.c:314 #12 0x000000000041e8e2 in select_qresync (cmd=<value optimized out>, ---Type <return> to continue, or q <return> to quit--- readonly=<value optimized out>) at cmd-select.c:243 #13 select_open (cmd=<value optimized out>, readonly=<value optimized out>) at cmd-select.c:320 #14 cmd_select_full (cmd=<value optimized out>, readonly=<value optimized out>) at cmd-select.c:382 #15 0x0000000000420ead in client_command_input (cmd=0x70a458) at client.c:612 #16 0x0000000000420f8d in client_command_input (cmd=0x70a458) at client.c:661 #17 0x00000000004211b5 in client_handle_next_command (client=0x709ff0) at client.c:702 #18 client_handle_input (client=0x709ff0) at client.c:714 #19 0x0000000000421a5c in client_input (client=0x709ff0) at client.c:753 #20 0x00000000004aa7cd in io_loop_handler_run (ioloop=<value optimized out>) at ioloop-epoll.c:208 #21 0x00000000004a9c38 in io_loop_run (ioloop=0x707cc0) at ioloop.c:335 #22 0x0000000000429726 in main (argc=<value optimized out>, argv=<value optimized out>, envp=<value optimized out>) at main.c:327
It's a public mailing list folder, so I've uploaded it to http://david.woodhou.se/bluez-maildir.tar.gz
Filed as Red Hat bug #625907: https://bugzilla.redhat.com/show_bug.cgi?id=625207
-- dwmw2
On Wed, 2010-08-18 at 22:27 +0100, David Woodhouse wrote:
Aug 18 22:07:31 twosheds IMAP(dwmw2): : Panic: file mail-index-transaction.c: line 637 (mail_index_transaction_lookup): assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 1:* (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757)))
Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e
On Thu, 2010-08-19 at 18:37 +0100, Timo Sirainen wrote:
Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e
Thanks. Obviously you've been able to test on exactly the same mailbox I'm using, so you'll not be surprised to hear that the patch works fine here too.
Do shout if you see anything that could be improved about the client's behaviour, by the way -- this is Evolution's 'imapx' back end.
It's including sequence numbers working backwards exponentially from the end of the folder -- so for a folder which had N mails last time we looked at it, we'll include sequences N-9, N-27, N-81, N-243, N-729, etc. in the QRESYNC request.
Does that seem reasonable?
-- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
On Thu, 19 Aug 2010 18:37:16 +0100, Timo Sirainen <tss@iki.fi> wrote:
On Wed, 2010-08-18 at 22:27 +0100, David Woodhouse wrote:
Aug 18 22:07:31 twosheds IMAP(dwmw2): : Panic: file mail-index-transaction.c: line 637 (mail_index_transaction_lookup): assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 1:* (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757)))
Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e
your this fix me its clean up : enjoy
On Thu, 2010-08-19 at 18:37 +0100, Timo Sirainen wrote:
On Wed, 2010-08-18 at 22:27 +0100, David Woodhouse wrote:
Aug 18 22:07:31 twosheds IMAP(dwmw2): : Panic: file mail-index-transaction.c: line 637 (mail_index_transaction_lookup): assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq)
A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 1:* (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757)))
Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/70fa6178380e
Hm, looking at RFC5162 again I realise that SELECT command isn't actually valid. The '1:*' for the known-uids is not permitted. From the formal syntax in §6:
capability =/ "QRESYNC"
select-param = "QRESYNC" SP "(" uidvalidity SP mod-sequence-value [SP known-uids] [SP seq-match-data] ")" ;; conforms to the generic select-param ;; syntax defined in [IMAPABNF]
seq-match-data = "(" known-sequence-set SP known-uid-set ")"
uidvalidity = nz-number
known-uids = sequence-set ;; sequence of UIDs, "*" is not allowed
known-sequence-set = sequence-set ;; set of message numbers corresponding to ;; the UIDs in known-uid-set, in ascending order. ;; * is not allowed.
known-uid-set = sequence-set ;; set of UIDs corresponding to the messages in ;; known-sequence-set, in ascending order. ;; * is not allowed.
§3.1 says: If the list of known UIDs was also provided, the server should only report flag changes and expunges for the specified messages. If the client did not provide the list of UIDs, the server acts as if the client has specified "1:<maxuid>", where <maxuid> is the mailbox's UIDNEXT value minus 1.
So instead of giving the known-uid set '1:*', the client should actually have omitted the optional known-uid parameter completely. It *should* have sent this command:
A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757)))
Dovecot doesn't like that though:
A00131 BAD Error in IMAP command SELECT: Invalid QRESYNC parameters
-- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
On Sat, 2010-08-21 at 16:15 +0100, David Woodhouse wrote:
A00131 SELECT lists.bluez (QRESYNC (1154090296 1861 (1,120,1578,2064,2226,2280,2298 1,120,12037,12523,12685,12739,12757)))
Dovecot doesn't like that though:
A00131 BAD Error in IMAP command SELECT: Invalid QRESYNC parameters
Whops. Looks like I read the RFC a bit wrong. Fixed in v2.0 and v1.2 hg now. I guess I should release 1.2.14 then. Could you try that the fix works properly? At least it doesn't give any errors anymore. http://hg.dovecot.org/dovecot-1.2/rev/7e959d397a35
On Mon, 2010-08-23 at 15:40 +0100, Timo Sirainen wrote:
Whops. Looks like I read the RFC a bit wrong. Fixed in v2.0 and v1.2 hg now. I guess I should release 1.2.14 then. Could you try that the fix works properly? At least it doesn't give any errors anymore. http://hg.dovecot.org/dovecot-1.2/rev/7e959d397a35
Looks like it's working; thanks. Tested against 1.2.13.
And thanks for not (yet) making it reject the invalid command with the 1:* in it -- I'll need to come up with a strategy for migrating to the 'correct' command on the client side, given that older versions of dovecot won't accept it.
I'll probably make the Evolution client code start off by trying the correct command, and then retry with the bogus '1:*' if that fails.
I don't really want to just 'fix' the client and let people get errors with older versions of Dovecot, even though QRESYNC support is optional.
-- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
On Mon, 2010-08-23 at 17:33 +0100, David Woodhouse wrote:
And thanks for not (yet) making it reject the invalid command with the 1:* in it
I changed it in v2.0.
-- I'll need to come up with a strategy for migrating to the 'correct' command on the client side, given that older versions of dovecot won't accept it.
I'll probably make the Evolution client code start off by trying the correct command, and then retry with the bogus '1:*' if that fails.
Can't you simply send 1:<last uid you've seen>? Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too.
On Mon, 2010-08-23 at 18:04 +0100, Timo Sirainen wrote:
On Mon, 2010-08-23 at 17:33 +0100, David Woodhouse wrote:
And thanks for not (yet) making it reject the invalid command with the 1:* in it
I changed it in v2.0.
-- I'll need to come up with a strategy for migrating to the 'correct' command on the client side, given that older versions of dovecot won't accept it.
I'll probably make the Evolution client code start off by trying the correct command, and then retry with the bogus '1:*' if that fails.
Can't you simply send 1:<last uid you've seen>?
I *might* be able to get away with that, and fetch flags for any newer messages at the same time as I fetch the headers for those messages. I'll check.
Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too.
1:4294967295 doesn't really fill me with joy either -- that assumes that a UID is limited to 32 bits unsigned... and that other servers won't fall over when presented with that number.
-- dwmw2
On Thu, 2010-08-26 at 14:32 +0100, David Woodhouse wrote:
Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too.
1:4294967295 doesn't really fill me with joy either -- that assumes that a UID is limited to 32 bits unsigned...
It is, as defined by RFC 3501.
and that other servers won't fall over when presented with that number.
Well, those servers would also be broken then.. I think servers can typically handle such UID better than clients (many clients use signed 32bit ints). I think there's a good chance it would work fine with all servers that support QRESYNC.
On Thu, 2010-08-26 at 17:02 +0100, Timo Sirainen wrote:
On Thu, 2010-08-26 at 14:32 +0100, David Woodhouse wrote:
Or if you want flags for messages you haven't even seen yet, 1:4294967295 should work too.
1:4294967295 doesn't really fill me with joy either -- that assumes that a UID is limited to 32 bits unsigned...
It is, as defined by RFC 3501.
and that other servers won't fall over when presented with that number.
Well, those servers would also be broken then.. I think servers can typically handle such UID better than clients (many clients use signed 32bit ints). I think there's a good chance it would work fine with all servers that support QRESYNC.
OK, I'll do that then. Thanks.
-- dwmw2
participants (3)
-
David Woodhouse
-
fakessh
-
Timo Sirainen