On Tuesday 05 October 2010, Chris Darroch wrote: > I stared at the definition of crypt_data in crypt.h, poked > around at various things, then gave up and went for quick bike > ride. The answer immediately popped to mind: I'd set my > ThreadStackSize really low, to 64 KB, and while that usually lets > you run without trouble on a Linux box, crypt_data contains about > 256 KB worth of arrays and it was overflowing the per-thread > stack. Live and learn.
This is PR 49437. crypt_data is a bit more than 128K on my Linux box. Any opinions how this could be improved? - use malloc/free instead. This may be bad for performance (e.g. glibc's malloc will use mmap/munmap by default for blocks > 128K, which is expensive) - create and destroy a temporary pool from the global pool - add a function apr_password_validate_ex that accepts a temp pool. This is only possible in apr-util 1.4.x - leave the current behaviour and document that ThreadStackSizes lower than 256K are problematic on Unix. I am leaning towards just fixing the documentation, even if that may mean that something like 60-100K per thread are used just for doing crypt().
