apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: segfault in apr_atomic_cas
Date Thu, 25 Sep 2003 15:20:28 GMT
> From: William A. Rowe, Jr. [mailto:wrowe@apache.org]
> Sent: Thursday, September 25, 2003 5:23 AM

> At 07:06 PM 9/24/2003, Blair Zajac wrote:
> >Yes, I brought this up a month ago.
> >
> >See the thread with the subject
> >
> >"unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump"
> >
> >Sander responded there, but there's been no work on it yet.
> 
> 
> I responded - prove that my changes no longer require any mutex/interlocs
> such as atomics.  Can we reduce this back to simple math?
> 
> If we can, let's keep the good changes and back out the atomics.
> 
> Others responded, "lets ditch nested locks".  I'm -0.5 on that suggestion.

This isn't even hitting nested locks.  It's hitting the mutex prior
to the atomics being initialized, which is where the problem lies.

This (not so nice) patch will solve it.  It's either this or back out
the atomics change.


Sander

Index: memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.198
diff -u -r1.198 apr_pools.c
--- memory/unix/apr_pools.c     3 Sep 2003 17:12:18 -0000       1.198
+++ memory/unix/apr_pools.c     25 Sep 2003 15:14:24 -0000
@@ -555,6 +555,13 @@

     apr_pool_tag(global_pool, "apr_global_pool");

+    /* strikerXXX: This has to happen here because mutexes might be backed by
+     * strikerXXX: atomics.  It used to be snug and safe in apr_initialize().
+     */
+    if ((rv = apr_atomic_init(global_pool)) != APR_SUCCESS) {
+        return rv;
+    }
+
 #if APR_HAS_THREADS
     {
         apr_thread_mutex_t *mutex;
Index: misc/unix/start.c
===================================================================
RCS file: /home/cvs/apr/misc/unix/start.c,v
retrieving revision 1.70
diff -u -r1.70 start.c
--- misc/unix/start.c   6 Jan 2003 23:44:32 -0000       1.70
+++ misc/unix/start.c   25 Sep 2003 15:14:24 -0000
@@ -99,9 +99,12 @@

     apr_pool_tag(pool, "apr_initialize");

-    if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
-        return status;
-    }
+    /* strikerXXX: apr_atomic_init() used to be called from here aswell.
+     * strikerXXX: Pools rely on mutexes though, which can be backed by
+     * strikerXXX: atomics.  Due to this circular dependency
+     * strikerXXX: apr_pool_initialize() is taking care of calling
+     * strikerXXX: apr_atomic_init() at the correct time.
+     */

     apr_signal_init(pool);


Mime
View raw message