httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <bnicho...@novell.com>
Subject Re: util_ldap [Bug 29217] - Remove references to calloc() and free()
Date Thu, 10 Jun 2004 14:31:24 GMT
   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 

>>> minfrin@sharp.fm 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
--

Mime
View raw message