Fix the rest of the apr_pool_userdata_setn() bogosity w.r.t. DSO modules.

It's totally unsafe to use apr_pool_userdata_setn() in the post_config
phase of a module, since on some platforms when the DSO gets reloaded
between phases, the data segment will be at a different address on the
second phase and the userdata_get() call will fail.

PR: 9413
Submitted by: Tsuyoshi Sasamoto <nazonazo@super.win.ne.jp>

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/ssl@95287 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/ssl_scache.c b/ssl_scache.c
index 9f7f8513efd640f00592792f7455788448e2bc55..9406c38e282ec30465f89f6b7c760f1f650620e7 100644 (file)
--- a/ssl_scache.c
+++ b/ssl_scache.c
@@ -94,8 +94,8 @@ void ssl_scache_init(server_rec *s, apr_pool_t *p)
 
         apr_pool_userdata_get(&data, userdata_key, s->process->pool);
         if (!data) {
-            apr_pool_userdata_setn((const void *)1, userdata_key,
-                                   apr_pool_cleanup_null, s->process->pool);
+            apr_pool_userdata_set((const void *)1, userdata_key,
+                                  apr_pool_cleanup_null, s->process->pool);
             return;
         }
         if (mc->nSessionCacheMode == SSL_SCMODE_SHMHT)