[Dovecot] Assertion failed: (pos < input->size)
Oct 21 10:04:05 alchemy dovecot: imap-login: Login: user=<paulproteus>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS Oct 21 10:05:44 alchemy dovecot: IMAP(paulproteus): file message-decoder.c: line 289 (message_decode_body): assertion failed: (pos < input->size) Oct 21 10:05:44 alchemy dovecot: IMAP(paulproteus): Raw backtrace: imap [0x80c8e10] -> imap [0x80c8d1c] -> imap(message_decoder_decode_next_block+0x868) [0x80c58a8] -> /usr/local/lib/dovecot/imap/lib20_fts_plugin.so [0xb7f7f2f5] -> imap [0x805f526] -> imap [0x805f8a8] -> imap(io_loop_handle_timeouts+0x10b) [0x80cf71b] -> imap(io_loop_handler_run+0x69) [0x80d0169] -> imap(io_loop_run+0x28) [0x80cf5f8] -> imap(main+0x4ac) [0x8068dec] -> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7e29050] -> imap [0x805b941] Oct 21 10:05:44 alchemy dovecot: child 14390 (imap) killed with signal 6
Assertion failed. This happened when doing a "SEARCH TEXT delicious". I 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, and if you need more info just reply saying "more info" and I'll go through the usual debugging steps.
-- Asheesh.
-- It is much easier to be critical than to be correct. -- Benjamin Disraeli
On Sun, 2007-10-21 at 10:37 -0700, Asheesh Laroia wrote:
Oct 21 10:04:05 alchemy dovecot: imap-login: Login: user=<paulproteus>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS Oct 21 10:05:44 alchemy dovecot: IMAP(paulproteus): file message-decoder.c: line 289 (message_decode_body): assertion failed: (pos < input->size)
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.. :)
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.
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.
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.
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!
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 Identity"
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
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
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.
participants (2)
-
Asheesh Laroia
-
Timo Sirainen