dovecot - Aug 2008 - Dovecot-1.1.2 segfaults in mail_cache_header_fields_get_offset

Dovecot 1.1.2 crashes reliably for me now on a Mac OS X machine.   
Here's some info:

--- Telnet session ---
$ telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK Dovecot ready.
a login user1 password
a OK Logged in.
b select inbox
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]  
Flags permitted.
* 1 EXISTS
* 1 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1218731580] UIDs valid
* OK [UIDNEXT 2] Predicted next UID
b OK [READ-WRITE] Select completed.
c fetch 1 rfc822.size
Connection closed by foreign host.

--- Error log ---
dovecot: Aug 29 11:24:30 Info: imap-login: Login: user=<user1>,  
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured
dovecot: Aug 29 11:24:33 Error: IMAP(user1): Corrupted transaction log  
file /Volumes/Spool/spool/user1/mail/dovecot.index.log: hdr.size too  
large (75497472)
dovecot: Aug 29 11:24:33 Warning: IMAP(user1): fscking index file / 
Volumes/Spool/spool/user1/mail/dovecot.index
dovecot: Aug 29 11:24:48 Error: child 66917 (imap) killed with signal 11

--- Backtrace ---
mail_cache_header_fields_get_offset + 214
mail_cache_header_fields_read + 37
mail_cache_open_and_verify + 167
mail_cache_field_exists + 77
index_mail_set_seq + 306
index_storage_search_next_nonblock + 464
mailbox_search_next + 52
imap_fetch + 345
cmd_fetch + 639
client_command_input + 33
client_command_input + 463
client_handle_input + 242
client_input + 151
io_loop_handler_run + 272
io_loop_run + 39
main + 1671
start + 52

If I do the exact same telnet all over again, the imap process crashes  
in the same place, but without reporting the "fscking index file"  
error first.  Attached are all the post-fsck dovecot* files from the  
user's inbox maildir.

For other users I see this error before imap crashes:
dovecot: Aug 29 11:45:23 Error: IMAP(user2): Rebuilding index file / 
Volumes/Spool/spool/user2/mail/dovecot.index: CPU architecture changed
Attached are pre- and post-rebuild copies of that user's dovecot*  
files, and also a copy from after a second telnet session which also  
crashed.

It's possible this is a 32/64-bit incompatibility issue (imap is a 64- 
bit program for me; mail might have been delivered by a 32-bit deliver  
or previously read by a 32-bit imap) but more likely the dovecot*  
files are just hosed in some way.

I can provide more information if you ask soon, but I can't keep this  
server broken for too long.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: user1-post.tgz
Type: application/octet-stream
Size: 607 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080829/8e368ef8/attachment-0008.obj>
-------------- next part --------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: user2-pre.tgz
Type: application/octet-stream
Size: 893 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080829/8e368ef8/attachment-0009.obj>
-------------- next part --------------
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: user2-post.tgz
Type: application/octet-stream
Size: 646 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080829/8e368ef8/attachment-0010.obj>
-------------- next part --------------
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: user2-final.tgz
Type: application/octet-stream
Size: 674 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080829/8e368ef8/attachment-0011.obj>

On Fri, 2008-08-29 at 12:58 -0500, Mike Abbott wrote:
> For other users I see this error before imap crashes:
> dovecot: Aug 29 11:45:23 Error: IMAP(user2): Rebuilding index file / 
> Volumes/Spool/spool/user2/mail/dovecot.index: CPU architecture changed
> Attached are pre- and post-rebuild copies of that user's dovecot*  
> files, and also a copy from after a second telnet session which also  
> crashed.
> 
> It's possible this is a 32/64-bit incompatibility issue (imap is a 64- 
> bit program for me; mail might have been delivered by a 32-bit deliver  
> or previously read by a 32-bit imap) but more likely the dovecot*  
> files are just hosed in some way.
That error message comes if CPU endianess changes (or the bit describing
it in the dovecot.index file header changes).

After wondering for a while, I can now reproduce your problems. The only
thing I had to do was to define WORDS_BIGENDIAN on a little-endian
machine. Why are you doing that? :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080830/4a7fa5a7/attachment-0002.bin>

On Fri, 2008-08-29 at 12:58 -0500, Mike Abbott wrote:
> dovecot: Aug 29 11:24:48 Error: child 66917 (imap) killed with signal 11
> 
> --- Backtrace ---
> mail_cache_header_fields_get_offset + 214
Fixed: http://hg.dovecot.org/dovecot-1.1/rev/b662b2beaf12

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080830/5425bce1/attachment-0002.bin>

> After wondering for a while, I can now reproduce your problems. The  
> only
> thing I had to do was to define WORDS_BIGENDIAN on a little-endian
> machine. Why are you doing that? :)
Er, you're right.  I built a "fat" (multi-architecture) Dovecot  
executable on a big-endian PowerPC/MacOSX machine and ran it on a  
little-endian Intel/MacOSX machine.  The configure script does not  
allow for the build and run systems to have different endianness.   
I'll find a way around that.  Thanks!