httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Jacques Clar" <>
Subject Re: [PATCH2] Re: Seg fault: race conditions in mod_mem_cache.c
Date Wed, 15 Sep 2004 21:27:08 GMT
>>> 09/15/04 12:41 PM >>>
>I'm still trying to learn the complete design though.  I see that 
>memcache_cache_free() can return with OBJECT_CLEANUP_BIT set, and that

>decrement_refcount() will react to it and free the memory if it is
registered as 
>a cleanup.  Will decrement_refcount() always be registered?  Just
wondering if 
>there are any code paths where we might leak memory.

An element will either be created or opened, both cases are registering

decrement_refcount() as the cleanup function to be called when the
is done.
To remove the 2 noted possible race situations, in addition to another
one in store_body(), we could add the following 2 recursive functions,
that have to be called under the protection of the lock (it is now for
all 3 cases of atomic_set32()):
static void memcache_clear_cleanup_bit(cache_object_t *obj)
    apr_uint32_t tmp_refcount = obj->refcount;
    if(tmp_refcount != apr_atomic_cas32(&obj->refcount, 
                                        obj->refcount &
                                        tmp_refcount)) {
static void memcache_set_cleanup_bit(cache_object_t *obj)
    apr_uint32_t tmp_refcount = obj->refcount;
    if(tmp_refcount != apr_atomic_cas32(&obj->refcount, 
                                        tmp_refcount |
                                        tmp_refcount)) {

One only additional thing is if I could call the set_cleanup_bit()
memcache_cache_free(), it would centralize all the bit setting into 
the 2 previous functions.
Thanks for your time on that case.

View raw message