dovecot - Aug 2014 - Assertion in istream.c::167 in POP3 mode when maildir content has wrong S value (using 2.2.13)

Hi,

the affected machine is running 2.2.13 on Gentoo x86_64. For me it looks like 
the old size is still in some struct or whereever even after the file has been 
renamed. I see that there are many commits following 2.2.13, is that possibly 
already fixed or do I need to dig in the code?

The original problem seems to be that maildrop uses the file size before piping 
the mail into spamassassin even if the mail is bigger afterwards. Not relevant 
here, but in case anyone wonders how this happens.

Greetings,

Eike

Error: Cached message size smaller than expected (81118 < 81308)
Error: Maildir filename has wrong S value, renamed the file from
/var/vpopmail/domains/example.org/user/.maildir/cur/1408452738.16341.mail,S=81118:2,
to
/var/vpopmail/domains/example.org/user/.maildir/cur/1408452738.16341.mail,S=81308:2,
Error: Corrupted index cache file
/var/vpopmail/domains/example.org/user/.maildir/dovecot.index.cache: Broken
physical size for mail UID 65
Panic: file istream.c: line 167 (i_stream_read): assertion failed: (old_size
<= _stream->pos - _stream->skip)
Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0x6bbef)
[0x7f50652a4bef]
 -> /usr/lib64/dovecot/libdovecot.so.0(+0x6bc4e) [0x7f50652a4c4e]
 -> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7f506525e2be]
 -> /usr/lib64/dovecot/libdovecot.so.0(i_stream_read+0x214) [0x7f50652ad904]
 -> /usr/lib64/dovecot/libdovecot.so.0(i_stream_read_data+0x3d)
[0x7f50652adfed]
 -> /usr/lib64/dovecot/libdovecot.so.0(message_get_body_size+0x9d)
[0x7f5065299b3d]
 -> /usr/lib64/dovecot/libdovecot-storage.so.0(index_mail_init_stream+0x200)
[0x7f506556f700]
 -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0x2dd0f) [0x7f506553cd0f]
 -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_get_stream+0x4b)
[0x7f506554915b]
 -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0x2dae7) [0x7f506553cae7]
 -> dovecot/pop3(client_create+0x56d) [0x40622d]
 -> dovecot/pop3() [0x404ea3]
 -> dovecot/pop3() [0x40508f]
 -> /usr/lib64/dovecot/libdovecot.so.0(+0x28346) [0x7f5065261346]
 -> /usr/lib64/dovecot/libdovecot.so.0(+0x28841) [0x7f5065261841]
 -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x4e) [0x7f50652b58de]
 -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xd7)
[0x7f50652b68b7]
 -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x9)
[0x7f50652b5969]
 -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f50652b59e8]
 -> /usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x13)
[0x7f50652635a3]
 -> dovecot/pop3(main+0x233) [0x404bf3]
 -> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f5064eb6db5]
 -> dovecot/pop3() [0x404d49]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20140820/cc0cef16/attachment.sig>

> The original problem seems to be that maildrop uses the file size before
> piping the mail into spamassassin even if the mail is bigger afterwards.
> Not relevant here, but in case anyone wonders how this happens.
Ok, this is not true. Maildrop is innocent, the problem is in vpopmail that 
does this wrong if the mail is filtered through spamassassin but afterwards 
_not_ piped through maildrop. Which is a stupid configuration anyway.

In case you have any patches to test I'm still interested.

Greetings,

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20140821/9a0f52a5/attachment.sig>