httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Jacques Clar" <JJC...@novell.com>
Subject Re: Seg fault: Possible race conditions in mod_mem_cache.c
Date Wed, 08 Sep 2004 23:23:31 GMT
>That's bad already.  At any time when there are n threads with a
>"handle" to a cache object, refcount ought to be n in order to be
able
>to free it when refcount goes to zero.
 
>Unless:
 
>Condition 1) a mutex is held between the time that a thread gets a
>handle to the cache object and when the thread increments the
refcount
>to reserve its handle
>*AND*
>Condition 2) Logic like that in decrement_refcount() which checks for
>refcount == 0 holds the very same mutex when it decrements and checks
>for refcount == 0, in order to insure that there are no other threads
>which are holding the mutex and are about to increment refcount.

In the current case, when calling memcache_cache_free(), the thread
hold the mutex, it was acquired back in create_entity() before doing
the new insertion/ejection. 
For decrement_refcount(), the increase was done under the protection
of the same mutex, but the decrease is not currently protected and
it looks like it might need that step.
As far as performance, I currently don't see any slow down on my 
box, but will run longer tests tomorrow morning.
 
Should I commit to 2.1 and add an entry in the status file for the 
2.0 branch? I will like to see that fixed in time for 2.0.51 (if there
is an rc3).
 
JJ

Mime
View raw message