search for: block_r

...y be missing something but was that done on purpose? Thanks. jeremy Index: base.rb =================================================================== --- base.rb (revision 24) +++ base.rb (working copy) @@ -181,7 +181,7 @@ @@? (.*?)/x BLOCKS_GROUP_RE = /\n{2,}(?! )/m - BLOCK_RE = /^(([a-z]+)(\d*))(#{A}#{C})\.(?::(\S+))? (.*)$/ + BLOCK_RE = /^(([a-z]+)(\d*))(#{A}#{C})\.(?::(\S+))? (.*)$/m SETEXT_RE = /\A(.+?)\n([=-])[=-]* *$/m ATX_RE = /\A(\#{1,6}) # $1 = string of #''s [ ]*

...tached the *.in and *.out files that I think are related to this IMAP conversation. On a different IMAP conversation with the same "SEARCH takes forever" problem, I attached a gdb to the running Dovecot and got this backtrace: (gdb) bt #0 parse_next_body_to_boundary (ctx=0x85746e8, block_r=0xbf92325c) at message-parser.c:332 #1 0x080c1b7d in message_parser_parse_next_block (ctx=0x85746e8, block_r=0xbf92325c) at message-parser.c:717 #2 0xb7f582c2 in fts_mailbox_search_next_nonblock (ctx=0x811c0c0, mail=0x811d380, tryagain_r=0xbf9232bb) at fts-storage.c:175 #3 0x08...

...ters. parse_next_body_to_boundary() assumes the '\r' might be the beginning of a boundary line, reducing the block size by one: src/lib-mail/message-parser.c: 404 /* no linefeeds in this block. we can just skip it. */ 405 ret = 0; 406 if (block_r->data[block_r->size-1] == '\r') { 407 /* this may be the beginning of the \r\n--boundary */ 408 block_r->size--; 409 } For a block size of 1 (e.g. the trailing '\r' character), dovecot ends up processing ze...

...ertion failed: (%s)", args=0xbfb4b1d4 "\017L\017\b?\002") at failures.c:423 #5 0x080d246c in i_panic ( format=0x80e5fec "file %s: line %d (%s): assertion failed: (%s)") at failures.c:190 #6 0x080cc246 in preparsed_parse_next_header_init (ctx=0x812b650, block_r=0xbfb4b24c) at message-parser.c:684 #7 0x080cbc0d in message_parser_parse_next_block (ctx=0x812b650, block_r=0xbfb4b24c) at message-parser.c:753 #8 0x080cbd5e in message_parser_parse_body (ctx=0x812b650, hdr_callback=0x80968a0 <parse_bodystructure_part_header>, context=0x812e...

...ats.c" i_stream_read(stream = 0x00000001100cbd20), line 80 in "istream.c" i_stream_read_data(stream = 0x00000001100cbd20, data_r = 0x0fffffffffffecc0, size_r = 0x0fffffffffffecc8, threshold = 1), line 361 in "istream.c" message_parser_read_more(ctx = 0x00000001100cc118, block_r = 0x0fffffffffffecb0, full_r = 0x0fffffffffffeb84), line 118 in "message- parser.c" parse_next_body_to_boundary(ctx = 0x00000001100cc118, block_r = 0x0fffffffffffecb0), line 330 in "message-parser.c" message_parser_parse_next_block(ctx = 0x00000001100cc118, block_r = 0x0f...

...ead (stream=0x814ae00) at istream- tee.c:122 #10 0x080de659 in i_stream_read (stream=0x814ae28) at istream.c:78 #11 0x080deea3 in i_stream_read_data (stream=0x814ae28, data_r=0xbfbfea88, size_r=0xbfbfea8c, threshold=1) at istream.c:322 #12 0x080d1744 in message_parser_read_more (ctx=0x8156468, block_r=0xbfbfea80, full_r=0xbfbfea27) at message-parser.c:117 #13 0x080d20ac in parse_next_body_to_eof (ctx=0x8156468, block_r=0xbfbfea80) at message-parser.c:411 #14 0x080d2ccf in message_parser_parse_next_block (ctx=0x8156468, block_r=0xbfbfea80) at message-parser.c:765 #15 0x080931d9 in index_mail_...

...:253 #11 0x00007fa38480cc14 in i_stream_unref (stream=0x56150ea9d338) at ../lib/istream.c:66 #12 0x00007fa3847dd179 in message_parse_header_deinit (_ctx=_ctx at entry=0x56150ea9d0c8) at ../lib-mail/message-header-parser.c:52 #13 0x00007fa3847deea1 in preparsed_parse_next_header (ctx=0x56150ea9d050, block_r=0x7ffc8222ca70) at ../lib-mail/message-parser-from-parts.c:310 #14 0x00007fa3847dfedc in message_parser_parse_next_block (ctx=ctx at entry=0x56150ea9d050, block_r=block_r at entry=0x7ffc8222ca70) at ../lib-mail/message-parser.c:838 #15 0x00007fa3847e0029 in message_parser_parse_header (ctx=0x56150e...

Hi, I have a couple of people bumping into an issue with their imap process crashing - from the users perspective, their mail client (thunderbird) just stops recieving new mail. It still seems to be possible for them to read their mail using squirell mail. When it crashes, it leaves behind a log message like this on the server: Aug 12 15:52:25 fury dovecot: imap-login: Login:

...tp://dovecot.org/pipermail/dovecot/attachments/20100917/fd660314/attachment-0002.mht> -------------- next part -------------- (gdb) bt full #0 0x00007ff667019002 in memchr () from /lib/libc.so.6 No symbol table info available. #1 0x00007ff667332f48 in parse_next_body_to_boundary (ctx=0xcd0d70, block_r=0x7fff6dc020a0) at message-parser.c:350 boundary = 0x0 data = 0xcd64e0 "\n<html><head><title>Sicher ist Sicher! Richten Sie jetzt Ihren Hotmail Junk-Mail Filter ein!</title></head><body style=\"margin:0px;\"><table dir=\&quot...

...in array_count_i (array=0x555555810d38) at ../../src/lib/array.h:155 No locals. #1 message_part_finish (ctx=ctx at entry=0x555555810ce0) at message-parser.c:227 __FUNCTION__ = "message_part_finish" #2 0x00007ffff73d132c in message_parser_parse_next_block (ctx=0x555555810ce0, block_r=block_r at entry=0x7fffffffdc40) at message-parser.c:1244 ret = <optimized out> eof = false full = false __FUNCTION__ = "message_parser_parse_next_block" #3 0x00007ffff73d2218 in message_search_msg_real (error_r=0x7fffffffdca0, parts=<optimiz...

I did some more optimisation. Most performance hit in Dovecot do "for loop" in string operations. In one case (in message-parser.c) "for loop" has another "for" inside with the same variable used as iterator. This case is very hard to optimise by compiler. I do changes only in top functions listed in oprofile. Maybe I do more in future. Code was analysed and

...in i_panic (format=0x4d6e20 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:187 args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffdf40, reg_save_area = 0x7fffffffde80}} #4 0x00000000004a26d3 in message_parser_parse_next_block (ctx=0x635448, block_r=0x7fffffffdf80) at message-parser.c:764 ret = -1 eof = false __PRETTY_FUNCTION__ = "message_parser_parse_next_block" #5 0x000000000045e8e8 in index_mail_cache_parse_continue (_mail=0x630848) at index-mail.c:1263 mail = (struct index_mail *) 0x630848...