reconstruct crash in cyrus-imapd-2.4.4

Giles Malet gdmalet+cyrusdevel at
Thu Nov 25 02:12:46 EST 2010

Hello folks,

We seem to have a bug in mailbox renames in 2.4.4 that is leaving 
mailboxes in funny states. I think the new mailbox is not added to the 
mboxlist yet the old is removed, and the folder is untouched on disk.... 
but I got sidetracked on that trying to do reconstruct -rf to get the 
lost folders back - and that crashes reconstruct! Doing -rfx instead 
avoids the crash, but has the side-effect of course of clobbering the 
mailbox flags.

The problem is in mboxlist_createmailbox_full() in mboxlist.c:

     struct mailbox *newmailbox = NULL;

     if (!dbonly && !isremote) {
         /* Filesystem Operations */
         r = mailbox_create(name, newpartition, acl, uniqueid,
                            options, uidvalidity, &newmailbox);

     /* all is well - activate the mailbox */
     mboxent = mboxlist_makeentry(newmailbox->mbtype, newmailbox->part,

In our case, that `if' statement is false (dbonly=1), so newmailbox is 
not initialised:

Program received signal SIGSEGV, Segmentation fault.
0x08055766 in mboxlist_createmailbox_full (
     name=0x81b5128 "user.testmail.watpd", mbtype=0, partition=0x0, 
     userid=0x809df95 "cyrus", auth_state=0x0, options=1,
     uidvalidity=1290667775, copyacl=0x0, uniqueid=0x0, localonly=0,
     forceuser=0, dbonly=1) at mboxlist.c:617
617         mboxent = mboxlist_makeentry(newmailbox->mbtype, 

(gdb) print newmailbox
$1 = (struct mailbox *) 0x0

This is on a cyrus murder, if that matters.... If I can get reconstruct 
to work I can make some unhappy users a bit happier, then work on 
finding what's causing the damage in renames.

BTW, I turned off delayed_delete and delayed_expunge as I heard there 
were bugs there (probably because of the rename problem), but no luck.

Any tips on fixing this greatly appreciated :-)


More information about the Cyrus-devel mailing list