Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <40C9D56B.7090309@sharp.fm>
Date: Fri, 11 Jun 2004 17:53:15 +0200
From: Graham Leggett <minfrin@sharp.fm>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040514
MIME-Version: 1.0
To: Brad Nicholes <BNICHOLES@novell.com>
Cc: dev@httpd.apache.org
Subject: Re: util_ldap [Bug 29217]  -  Remove references to calloc()	and
 free()
References: <s0c89572.053@sinclair.provo.novell.com>
In-Reply-To: <s0c89572.053@sinclair.provo.novell.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Brad Nicholes wrote:

>    It appears to me that if it doesn't handle low memory situations or
> it is giving false positives, those are separate issues from pools vs.
> calloc/free.  I still think we need to implement some better monitoring
> or logging code in the cache_mgr and enhance the cache-status pages so
> that we can track things like false positives.  Maybe tracking the
> entries by user name and authentication state rather than just the
> number entries and how often the cache was hit.

This is a definite plan.

>    Maybe the real problem is with the locking.  In fact just taking a
> quick scan through the code again, I am seeing something that bothers me
> in util_ldap_cache_comparedn()
> 
>         if (curl) {
>             /* compare successful - add to the compare cache */
>             LDAP_CACHE_RDLOCK();
>             newnode.reqdn = (char *)reqdn;
>             newnode.dn = (char *)dn;
>             util_ald_cache_insert(curl->dn_compare_cache, &newnode);
>             LDAP_CACHE_UNLOCK();
>         }
> 
> It appears to be acquiring a read lock but then inserts a new node into
> the cache.  Shouldn't it be acquiring a write lock before doing an
> insert?

I would say it does.

Another thing I noticed was that it didn't seem to handle the case when 
it was half way through adding something to the cache, and the attempt 
to do so failed. I plan to look at the code again in the next day or two 
to see if I can better figure out what it is doing.

Regards,
Graham
--