Re: Seg fault: Possible race conditions in mod_mem_cache.c

[Jean-Jacques Clar]

>It should not be possibe for two threads to atomically decrement the refcount on the same object to 0.  I think there is a small window in there where it is possible to have the decs happening on both CPUs one after the other making that bug possible in decrement_refcount() and memcache_cache_free().   >Sounds >like a bug in netware's apr_atomic_dec() function.   Sorry but when running the same test on SLES9 with 2.0.51rc1, my error_log is full of threads segfaulting.   If I protect decrement_refcount() code using the lock, things are fine both on NetWare and SLES.   @@ -267,13 +269,13 @@  {      cache_object_t *obj = (cache_object_t *) arg;   +    if (sconf->lock) { +        apr_thread_mutex_lock(sconf->lock); +    }      /* If obj->complete is not set, the cache update failed and the       * object needs to be removed from the cache then cleaned up.       */      if (!obj->complete) { -        if (sconf->lock) { -            apr_thread_mutex_lock(sconf->lock); -        }          /* Remember, objects marked for cleanup are, by design, already           * removed from the cache. remove_url() could have already           * removed the object from the cache (and set obj->cleanup) @@ -282,9 +284,6 @@              cache_remove(sconf->cache_cache, obj);              obj->cleanup = 1;          } -        if (sconf->lock) { -            apr_thread_mutex_unlock(sconf->lock); -        }      }        /* Cleanup the cache object */ @@ -293,6 +292,10 @@              cleanup_cache_object(obj);          }      } +    if (sconf->lock) { +        apr_thread_mutex_unlock(sconf->lock); +    } +         return APR_SUCCESS;  }