...

Ah, makes sense, I feel dumb now :) Here's a backtrace from imap.core, I can do more with the core if it helps #0 0x182bc437 in kill () from /lib/libc.so.6 #1 0x182bc3d6 in raise () from /lib/libc.so.6 #2 0x182baf02 in abort () from /lib/libc.so.6 .. Not having debugging information stripped would be helpful :)

Well now I feel dumber :) FreeBSD uses the install-strip target in
the Makefile to install the binaries, so even if I have -g in COPTS
the binaries get stripped. I overwrote the binaries with those from
src/ and reproduced the crash (which is as easy and opening the
folder in an IMAP client), here's the new backtrace

(gdb) bt #0 0x182bc437 in kill () from /lib/libc.so.6 #1 0x182bc3d6 in raise () from /lib/libc.so.6 #2 0x182baf02 in abort () from /lib/libc.so.6 #3 0x080b7355 in i_internal_panic_handler (fmt=0x0, args=0x0) at
failures.c:382 #4 0x080b6dc9 in i_panic (format=0x0) at failures.c:180 #5 0x0807c19d in mbox_sync_read_and_move (sync_ctx=0xbfbfe8b0, mail_ctx=0xbfbfe580, mails=0x80fb000, seq=405589544, idx=0, padding=3217024224, move_diff=37, expunged_space=0, end_offset=3333, first_nonexpunged=true) at mbox-sync-rewrite.c:405 #6 0x0807c70e in mbox_sync_rewrite (sync_ctx=0xbfbfe8b0, mail_ctx=0x0, end_offset=3333, move_diff=37, extra_space=63, first_seq=1, last_seq=0) at mbox-sync-rewrite.c:507 #7 0x08076df9 in mbox_sync_handle_missing_space
(mail_ctx=0xbfbfe7b0) at mbox-sync.c:854 #8 0x0807756b in mbox_sync_loop (sync_ctx=0xbfbfe8b0,
mail_ctx=0xbfbfe7b0, partial=true) at mbox-sync.c:1158 #9 0x08078326 in mbox_sync_do (sync_ctx=0xbfbfe8b0,
flags=MBOX_SYNC_REWRITE) at mbox-sync.c:1480 #10 0x08078bea in mbox_sync (mbox=0x80e5840, flags=MBOX_SYNC_REWRITE)
at mbox-sync.c:1732 #11 0x08070456 in mbox_storage_close (box=0x80e5840) at mbox- storage.c:1063 #12 0x080a8607 in mailbox_close (_box=0x0) at mail-storage.c:371 #13 0x08058a4d in cmd_logout (cmd=0x80e8044) at cmd-logout.c:18 #14 0x0805b12c in client_handle_input (cmd=0x80e8044) at client.c:377 #15 0x0805b21d in _client_input (context=0x80e8000) at client.c:428 #16 0x080bd39c in io_loop_handler_run (ioloop=0x80e4000) at ioloop- poll.c:199 #17 0x080bccb8 in io_loop_run (ioloop=0x80e4000) at ioloop.c:281 #18 0x08064078 in main (argc=3, argv=0x0, envp=0x0) at main.c:280

...

Sure, you can get it here: You don't have X-IMAPbase or X-IMAP header in the first mail, so I
guess you're also reading and modifying the mailbox outside Dovecot? That by itself shouldn't break it as long as the locking is done correctly.
But I guess your problem is somehow related to that. I couldn't anyway
cause a crash using the file.

Procmail writes to the folders, but it uses dotlocks, and I don't
have logs of it crashing, whereas I do have logs of dovecot
crashing :) I'm confused as to what the last sentence says, do you
mean that you were able to reproduce the crash?