On Thu, 2009-10-29 at 12:11 +0200, Nikita Koshikov wrote:
On Wed, 28 Oct 2009 14:17:52 -0400 Timo Sirainen tss@iki.fi wrote:
On Wed, 2009-10-28 at 10:39 +0200, Nikita Koshikov wrote:
Oct 26 15:26:38 IMAP(gozhda.a@domain.com): Panic: data stack: Out of memory when allocating 268435472 bytes Oct 26 15:26:38 IMAP(gozhda.a@domain.com): Error: *** glibc detected *** imap: double free or corruption (!prev): 0x0812ba00 ***
Oh, the double free is because of broken handling of out-of-memory error. http://hg.dovecot.org/dovecot-1.2/rev/acfef2f0fec3 probably fixes that.
Sorry, but this patch didn't help.
Not with the "out of memory", but did it get rid of the "double free or corruption" error?
Hmm. So I guess there's no memory corruption causing this, but I don't really see why it would try to allocate that much memory. 268435472 in hex is 0x10000010, which is an interesting number but doesn't really help much either. 268435456 is 256M which is max mail_process_size config setting, maybe this values is in use ?
I guess it's just exponentially increasing the buffer size then until it reaches mail_process_size.
I recompile dovecot binaries with debug symbols, but seemed that gdb backtrace is broken.
Yeah, it is. Hmm. Since the core isn't working, can you attach gdb to imap process while it's still running? So something like:
- open the account so imap process starts
- gdb -p <imap process pid>
- gdb command: c
- cause imap to crash -> gdb should stop
- gdb command: bt full