httpd-dev mailing list archives

>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;
 }