On Jun 22, 2008, at 6:11 PM, Ralf Hildebrandt wrote:
* Timo Sirainen <tss@iki.fi>:
Well, these really aren't good and there's a good chance that cores won't help finding out the cause. The best way would be to run via valgrind:
login_executable = /usr/bin/valgrind /usr/local/libexec/dovecot/ imap-login
I can try that.
I don't really have any good guesses as to why these could be happening, but could you post your dovecot -n output? Maybe there are some less common settings..
attached
Didn't seem to have anything special. You could also try if the patch below changes anything. Although I haven't heard other people getting heap corruption in v1.1, so it shouldn't be that common problem.. diff -r 65c19e970618 src/login-common/main.c --- a/src/login-common/main.c Sun Jun 22 14:02:54 2008 +0300 +++ b/src/login-common/main.c Sun Jun 22 19:37:45 2008 +0300 @@ -407,8 +407,8 @@ processes pretty safe to reuse for new connections since the attacker won't be able to find anything interesting from the memory. */ - default_pool = system_clean_pool; - data_stack_set_clean_after_pop(TRUE); + /*default_pool = system_clean_pool; + data_stack_set_clean_after_pop(TRUE);*/ /* NOTE: we start rooted, so keep the code minimal until restrict_access_by_env() is called */