Brad Nicholes wrote:
I guess that is a possibility but I still don't understand what the
problem is with using calloc() and free() for the ldap caching code. This seems to be a common thing to do when global memory needs to be
allocated and deallocated constantly. To avoid having the memory grow
uncontrolably, you have to be able to control it at a much finer level
than apr_pool allows you.
What I've found in the LDAP code is that it isn't very defensive, most of the code simply assumes the rest of the code worked - it has resulted in me finding all sorts of side problems in the code, but not the real problem - the false negatives the code reports after it has been idle for a long time.
Changing malloc and free into something more bulletproof (or at least more robust), like pools and/or the reslist stuff would make the code more resilient, and for me, easier to debug :)
Regards, Graham --
