Recently, I started seeing the following error in my mail logs on RHEL4 servers:
Sep 30 18:36:26 mx01 pop3(woody): file lib.c: line 37 (nearest_power): assertion failed: (num <= ((size_t)1 << (BITS_IN_SIZE_T-1))) Sep 30 18:36:26 mx01 dovecot: child 11238 (pop3) killed with signal 6
This has been happening since dovecot-0.99.11-10.EL4, released on 18 August 2011. The changelog for this release shows:
- fix potential crash when parsing header names that contain NUL characters (#728674)
It could be that this update introduced a bug, or it could simply be a coincidence and completely unrelated.
The problem is a malformed multi-part (rfc1341) message. These messages usually look something like this. In the headers, you'll see:
Content-type: multipart/mixed; boundary="M7qxj4rHbpfU"
The body, oversimplified, will look something like this:
Some text. --M7qxj4rHbpfU Content-type: foo foo foo foo foo foo foo foo foo foo --M7qxj4rHbpfU Content-type: text/plain; charset=us-ascii bar bar bar bar bar bar bar bar bar --M7qxj4rHbpfU--
This last line, the closing encapsulation boundary, indicates that there are no further parts:
--M7qxj4rHbpfU--
In cases where this crash happens, this line is missing. I suspect what's happening is that dovecot continue reading the next mail's headers as if it's part of the last part, until it reaches the new (unexpected) Content-type header.
To fix this, you can insert the missing boundary - copy one of the previous ones and add -- at the end. Or delete the offending mail - mutt -f will open the mailbox.
« Plesk error: webstatmng is failed OSX Tips: Disable .MobileBackups »
Thank you for your posts. In fact, when I tried to google up the issue by entering. “file lib.c: line 37 (nearest_power): assertion”, this site was the only one found. Very helpful. At least I knew that I’m not alone with this issue. Just pulled back previous version rpm from /var/spool/up2date and everything works great now.
You could just roll back to the previous version – dovecot-0.99.11-9.EL4 – that’s what I did. The update fixes a header issue, ironically, which I haven’t seen affect anything since RHEL4 came out.
I’m wondering is there a better solution for this issue. Firstly it is almost insane to search through huge mail files, and, secondly, there is no guarantee that this will not happen again. May be just install latest dovecot from dovecot.org. They have dovecot-2.0.14-1_130.el4.i386.rpm. I now it requires sqlite3 and may be something else. Just want to make sure that this will not cause problems on production server.
It is exactly when you cannot find the string ending in — when this happens, unless it is not multi-part and there are no boundaries.
I’m experiencing the same problem as of Oct 11. The only issue that I couldn’t find the –M7qxj4rHbpfU– pattern in my /var/spool/mail files. So I guess this happens with some other patterns as well.