On Thu, 2008-01-24 at 11:47 +0100, Wolfram Schlich wrote:
No symbol table info available. #1 0x1a2a88f1 in ?? () No symbol table info available. #2 0xb136ec5f in ?? () No symbol table info available. #3 0x00000001 in ?? () No symbol table info available. #4 0x00000000 in ?? () No symbol table info available. (gdb) --8<--
I have to say this machine is a Gentoo Hardened machine using a PaX kernel and PIE/SSP userland...
I remember I stopped using PaX a few years ago because I had trouble with gdb, but I don't remember if it was the same problem.
2008-01-24 05:16:00 +01:00; uluru; mail.err; dovecot: child 22235 (imap) killed with signal 11 2008-01-24 11:17:42 +01:00; uluru; mail.err; dovecot: IMAP(info): pool_system_malloc(): Out of memory 2008-01-24 10:58:42 +01:00; uluru; mail.err; dovecot: IMAP(someuser): pool_system_malloc(): Out of memory
So, only the crash from 05:16 produced a core, the others didn't... WTF?! :)) And yes, I restarted dovecot right after I installed the patched version...
Interesting. My patch was only for pool_alloconly_malloc(), because I thought the problem was with a single memory allocation call. But these two show that it also happens in another place. Maybe these really have some email (or something) that causes Dovecot to eat lots of memory?
Also the signal 11 is a different problem from these memory allocation problems.
But unfortunately without a usable backtrace or a way to reproduce this, I can't really do anything..