Renaud Métrich
2020-Nov-04 12:24 UTC
imap dumping core in libdovecot-storage with assert "(block_count == 0 || block_idx+1 == block_count)"
Hi,
I would like to report an issue which is 100% reproducible with a
specific mail available in the reproducer attached to Red Hat's bugzilla
<https://bugzilla.redhat.com/show_bug.cgi?id=1894418>
(https://bugzilla.redhat.com/attachment.cgi?id=1726535):
-------- 8< ---------------- 8< ---------------- 8< ----------------
8< --------
Return-Path: <XXXXXXXXX at XXXXXXX.XXX.XX>
X-Original-To: XXXXXXXXX at XXXXXXX.XXX.XX
Delivered-To: XXXXXXXXXXXXXXXX at XXXXXX.XX.XXX.XX
Received: from XXXXXXXXXXXXXXXXX.XXXXX.XX.XX (unknown [XX.XX.XXX.XXX])
by XXXXXX.XX.XXX.XX (Postfix) with ESMTP id XXXXXXXXXXX
for <XXXXXXXXX at XXXXXXX.XXX.XX>; Thu, 15 Oct 2020 23:11:45 +0200 (CEST)
Date: Thu, 15 Oct 2020 23:11:42 +0200
Subject: zoom
Message-ID: <XXXXXXXXXXXXXXXXXXXXXXXX.XXXXXXXXXXXXX at XXXXX.XXXXXXX.XXX>
From: "XXXXXXXXX at XXXXXXX.XXX.XX" <XXXXXXXXX at
XXXXXXX.XXX.XX>
To: XXXXXXXXX at XXXXXXX.XXX.XX
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
-------- 8< ---------------- 8< ---------------- 8< ----------------
8< --------
The email seems completely valid to me, but I'm no email expert.
When performing a "FETCH <ID> (BINARY.SIZE[1] BINARY.PEEK[1])"
operation, imap crashes with following backtrace:
-------- 8< ---------------- 8< ---------------- 8< ----------------
8< --------
(gdb) bt
[...]
#5 0x00007ffff7707a25 in i_panic (
format=format at entry=0x7ffff7b7b460 "file %s: line %d (%s):
assertion failed: (%s)") at failures.c:523
#6 0x00007ffff7ab5de7 in blocks_count_lines (full_input=0x5555557f1230,
ctx=0x7fffffffdb80)
at index-mail-binary.c:357
#7 index_mail_read_binary_to_cache (_mail=0x5555557e3b48, part=0x5555557e4678,
include_hdr=<optimized out>,
reason=<optimized out>, binary_r=0x7fffffffdc16,
converted_r=0x7fffffffdc17) at index-mail-binary.c:395
#8 0x00007ffff7b39c8b in index_mail_get_binary_size (lines_r=0x7fffffffdcc4,
size_r=0x7fffffffdd20,
include_hdr=false, part=0x5555557e4678, _mail=0x5555557e3b48) at
index-mail-binary.c:497
#9 index_mail_get_binary_stream (_mail=0x5555557e3b48, part=0x5555557e4678,
include_hdr=<optimized out>,
size_r=0x7fffffffdd20, lines_r=0x7fffffffdcc4, binary_r=<optimized
out>, stream_r=0x0) at index-mail-binary.c:557
#10 0x00007ffff7abd204 in mail_get_binary_size (mail=mail at
entry=0x5555557e3b48, part=0x5555557e4678,
include_hdr=<optimized out>, size_r=size_r at entry=0x7fffffffdd20,
lines_r=lines_r at entry=0x7fffffffdcc4)
at mail.c:342
#11 0x00007ffff7b7add8 in imap_msgpart_size (mail=0x5555557e3b48,
msgpart=0x5555557e0748,
size_r=size_r at entry=0x7fffffffdd20) at imap-msgpart.c:755
#12 0x000055555557917c in fetch_binary_size (ctx=0x5555557c97b0,
mail=<optimized out>, body=0x5555557dfa20)
at imap-fetch-body.c:212
#13 0x00005555555777e2 in imap_fetch_more_int (ctx=0x5555557c97b0, cancel=false)
at imap-fetch.c:562
#14 0x00005555555788ed in imap_fetch_more (ctx=0x5555557c97b0, cmd=cmd at
entry=0x5555557c95d8) at imap-fetch.c:617
#15 0x00005555555694b1 in cmd_fetch (cmd=0x5555557c95d8) at cmd-fetch.c:337
[...]
#28 0x0000555555566405 in main (argc=<optimized out>, argv=<optimized
out>) at main.c:523
-------- 8< ---------------- 8< ---------------- 8< ----------------
8< --------
This happens on latest dovecot.
Best regards,
Renaud METRICH
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20201104/732fb85e/attachment.html>
Timo Sirainen
2020-Nov-10 14:45 UTC
imap dumping core in libdovecot-storage with assert "(block_count == 0 || block_idx+1 == block_count)"
On 4. Nov 2020, at 13.24, Renaud M?trich <rmetrich at redhat.com> wrote:> I would like to report an issue which is 100% reproducible with a specific mail available in the reproducer attached to Red Hat's bugzilla <https://bugzilla.redhat.com/show_bug.cgi?id=1894418>(https://bugzilla.redhat.com/attachment.cgi?id=1726535 <https://bugzilla.redhat.com/attachment.cgi?id=1726535>): > When performing a "FETCH <ID> (BINARY.SIZE[1] > BINARY.PEEK[1])" operation, imap crashes with following backtrace:Thanks, this should fix it: diff --git a/src/lib-storage/index/index-mail-binary.c b/src/lib-storage/index/index-mail-binary.c index 2577f1afe5..f7bf984916 100644 --- a/src/lib-storage/index/index-mail-binary.c +++ b/src/lib-storage/index/index-mail-binary.c @@ -339,7 +339,7 @@ blocks_count_lines(struct binary_ctx *ctx, struct istream *full_input) i_stream_skip(full_input, skip); cur_block_offset += skip; - if (cur_block->input->eof) { + if (i_stream_read_eof(cur_block->input)) { /* go to the next block */ if (++block_idx == block_count) { i_assert(i_stream_read_eof(full_input)); -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20201110/a5dd5a05/attachment.html>
Timo Sirainen
2020-Nov-10 15:46 UTC
imap dumping core in libdovecot-storage with assert "(block_count == 0 || block_idx+1 == block_count)"
On 10. Nov 2020, at 15.45, Timo Sirainen <timo at sirainen.com> wrote:> > On 4. Nov 2020, at 13.24, Renaud M?trich <rmetrich at redhat.com <mailto:rmetrich at redhat.com>> wrote: >> I would like to report an issue which is 100% reproducible with a specific mail available in the reproducer attached to Red Hat's bugzilla <https://bugzilla.redhat.com/show_bug.cgi?id=1894418>(https://bugzilla.redhat.com/attachment.cgi?id=1726535 <https://bugzilla.redhat.com/attachment.cgi?id=1726535>): >> When performing a "FETCH <ID> (BINARY.SIZE[1] >> BINARY.PEEK[1])" operation, imap crashes with following backtrace: > > Thanks, this should fix it: > > diff --git a/src/lib-storage/index/index-mail-binary.c b/src/lib-storage/index/index-mail-binary.c > index 2577f1afe5..f7bf984916 100644 > --- a/src/lib-storage/index/index-mail-binary.c > +++ b/src/lib-storage/index/index-mail-binary.c > @@ -339,7 +339,7 @@ blocks_count_lines(struct binary_ctx *ctx, struct istream *full_input) > i_stream_skip(full_input, skip); > cur_block_offset += skip; > > - if (cur_block->input->eof) { > + if (i_stream_read_eof(cur_block->input)) { > /* go to the next block */ > if (++block_idx == block_count) { > i_assert(i_stream_read_eof(full_input));Actually, that breaks things. This one should be ok: diff --git a/src/lib-storage/index/index-mail-binary.c b/src/lib-storage/index/index-mail-binary.c index 2577f1afe5..80c319e050 100644 --- a/src/lib-storage/index/index-mail-binary.c +++ b/src/lib-storage/index/index-mail-binary.c @@ -339,13 +339,14 @@ blocks_count_lines(struct binary_ctx *ctx, struct istream *full_input) i_stream_skip(full_input, skip); cur_block_offset += skip; - if (cur_block->input->eof) { + if (i_stream_read_eof(cur_block->input)) { /* go to the next block */ - if (++block_idx == block_count) { + if (block_idx+1 == block_count) { i_assert(i_stream_read_eof(full_input)); ret = -1; break; } + block_idx++; cur_block++; cur_block_offset = 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20201110/55b8a029/attachment.html>
Seemingly Similar Threads
- imap dumping core in libdovecot-storage with assert "(block_count == 0 || block_idx+1 == block_count)"
- imap dumping core in libdovecot-storage with assert "(block_count == 0 || block_idx+1 == block_count)"
- replace istream and unref the old one...
- Plugin
- crash with dovecot 2.2: Panic: Buffer full