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]
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
participants (1)
-
Rolf Eike Beer