On Jun 22, 2008, at 6:11 PM, Ralf Hildebrandt wrote:

* Timo Sirainen <[EMAIL PROTECTED]>:

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 */

Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to