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.