dovecot - Dec 2010 - Crash in 2.0.8 dovecot/imap - information capture

My dovecot logs revealed a crash in the dovecot/imap process a few
days ago. It appears to have dereferenced 0x00000004 in the storage
shared lib. Unfortunately, I didn't get a core and I'm not sure how
to reproduce it. Dovecot 2.0.8 on linux32.

Two questions:

1) How can I be sure I get a core next time? I think it's because I
    run dovecot/imap under a mail uid and didn't have write permission
    to the cwd. Any way to verify that was it, and be sure it works?

2) What other settings would provide more info if it happens again?

Thanks!

dovecot.log excerpt:
Dec 10 08:43:53 master: Error: service(imap): child 30862 killed with 
signal 11 (core dumps disabled)
Dec 10 08:43:53 imap-login: Info: Login: user=<xx at yy.com>,
method=PLAIN,
rip=169.254.100.10, lip=169.254.100.100, mpid=2243

kernel dmesg:
imap[30862]: segfault at 4 ip b772ecd2 sp bfc90f90 error 4 in 
libdovecot-storage.so.0.0.0[b76e9000+b8000]

[~] # dovecot -n
# 2.0.8: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.33.2 i686  ext4
(not sure of exact config at time of crash, will capture next)

On Sun, 2010-12-12 at 10:51 -0500, Tom Talpey wrote:
> 1) How can I be sure I get a core next time? I think it's because I
>     run dovecot/imap under a mail uid and didn't have write permission
>     to the cwd. Any way to verify that was it, and be sure it works?
http://dovecot.org/bugreport.html explains all of the things you need to
get core dumps. Although some of those settings are v1.x specific, so I
should look into updating the page..

Anyway, you can also test that you really get core dumps by manually
sending a SEGV signal to one test imap process.
> 2) What other settings would provide more info if it happens again?
The gdb backtrace will be enough.
> Dec 10 08:43:53 master: Error: service(imap): child 30862 killed with 
> signal 11 (core dumps disabled)
Run "ulimit -c unlimited" before starting dovecot.