On Jan 15, 2009, at 7:28 PM, Ralf Hildebrandt wrote:
Well..
==10780== Invalid write of size 1
==10780== at 0x402499E: memcpy (mc_replace_strmem.c:402)
==10780== by 0x805B000: pool_system_clean_realloc (mempool-system-
clean.c:149)
==10780== by 0x804FC09: ssl_clean_realloc (ssl-proxy-openssl.c:729)
I did find that pool_system_clean_realloc() didn't handle shrinking
the memory area, fixed: http://hg.dovecot.org/dovecot-1.1/rev/17c73b14ed9d
But I'm not sure if that really caused the problem, because it only
says invalid size of 1. More likely valgrind just doesn't like that I
use glibc-specific malloc_usable_size(). I think I noticed the same
problem before too. So to avoid these you should disable using the
clean pool (perhaps I should disable it entirely by default - it's not
useful after all for what I originally thought it would have been):
diff -r 17c73b14ed9d src/login-common/main.c
--- a/src/login-common/main.c Thu Jan 15 21:36:26 2009 -0500
+++ b/src/login-common/main.c Thu Jan 15 21:40:12 2009 -0500
@@ -413,8 +413,8 @@ int main(int argc ATTR_UNUSED, char *arg
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 */
Then again perhaps using the clean pool really is the problem. You
could just see if after applying the above patch it runs without
crashes even without valgrind.
