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?