I agree that the LDAP code needs to do more error checking and between the work that you did, along with the holes that I plugged previously and the shared memory fixes that Mathieu Estrade did, I think the code is much more robust than it has ever been. Many of our NetWare customers use auth_ldap as the primary means of authentication because it is the easiest way to authenticate against eDirectory. Outside of the shared memory problems, since NetWare doesn't use it, we have run into the same issues that you have seen. But since these latest patches that have gone into 2.0.50-dev, those problems have gone away. At least on NetWare, switching to pools would make the code much more complex. Rather than simply calling calloc and free in the same way that we are calling apr_rmm_calloc() and apr_rmm_free(), we would have to implement essentially the same model using pools and reslists. It seems to me like using a sledge hammer to drive a finishing nail in this instance. Also in the end, it all boils down to malloc and free anyway. As far as debugging goes, I can understand why it might be easier using the pool debug code, but we have never been successful in making the pool debug code work on NetWare. Granted we probably haven't tried real hard mainly because NetWare already has some good memory debugging capabilities built into the OS. If debugging is a problem, I think it might be easier to implement some memory debugging code specifically for the LDAP_cache rather than trying to retrofit it with pools and reslists.
Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Thursday, June 10, 2004 4:59:30 AM >>> 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 --
