robustness ...

[Jure Pecar]

I was running a cvs snapshot of 2.2 from august 2002 for my personal mail
till now, when i upgraded to 2.2.1.

A folder for info-cyrus developed some strange behaviour a couple of
months ago: some clients would see a bounch of mail that was no longer
there (sylpheed), some clients would see it ok (sylpheed-claws), some
clients would not display it at al (jawmail webmail). It somehow became
corrupted in some subtle way. (reconstruct was not functional in that
snapshot)

So on to upgrade ... pretty straightforward, much less fun that i
expected. First lets see what's up with the info-cyrus folder: looks ok, i
try to delete the last mail that was delivered into it, imapd crashes:

Program received signal SIGSEGV, Segmentation fault.
mailbox_expunge (mailbox=0x8119be0, iscurrentdir=1, decideproc=0,
deciderock=0x0) at mailbox.c:1884
1884			cacheitem = CACHE_ITEM_NEXT(cacheitem);
(gdb) bt
#0  mailbox_expunge (mailbox=0x8119be0, iscurrentdir=1, decideproc=0,
#deciderock=0x0) at mailbox.c:1884 1  0x08054944 in cmd_expunge
#(tag=0x8133598 "53", sequence=0x0) at imapd.c:3354 2  0x0804ed87 in
#cmdloop () at imapd.c:907 3  0x0804dfdb in service_main (argc=1,
#argv=0x8128ed0, envp=0xbffffb5c) at imapd.c:569 4  0x0804cece in main
#(argc=1, argv=0xbffffb54, envp=0xbffffb5c) at service.c:514 5  0x401da627
#in __libc_start_main (main=0x804c6a4 <main>, argc=1, ubp_av=0xbffffb54,
#init=0x804b354 <_init>, fini=0x80920a0 <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffb4c) at
../sysdeps/generic/libc-start.c:129

Luckily, reconstruct -r fixed the problems.


Why am i writing all this? 
I still think that imapd should not crash or do other unreasonable things
(like looping with 100% cpu consumption) when confronted with corrupted
files. I had many interesting expiriences on our production system, where
fs badly crashed. IMHO Cyrus still needs some work in the robustness area.

If only i'd know more about programming ... 

--

Jure Pecar