You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Amund Elstad <Am...@ergo.no> on 2002/10/01 15:56:16 UTC

[PATCH] Threadsafety to mod_ssl dbm session cache

I am reposting a patch posted by Jeff Trawick which adds mutex protection to
the retrieve operation. Before I applied this patch, I  experienced the
following problems with 2.0.40 on win32:

	- Child process termination (status 3221225477 in error_log,
segfault?) - often twice or more every weekday. 
	- Infinite loops (I traced one to dbm_close:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12705) several times a
week. 

I applied the patch on September 17th and the server has been running
perfectly stable since. There has been no significant change in server load,
nor any other changes in software or hardware.

The extra mutex protection is in my experience required on win32 (probably
needed for other threaded MPMs as well), and IMO should be commited to cvs. 

Index: modules/ssl/ssl_scache_dbm.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_scache_dbm.c,v
retrieving revision 1.16
diff -u -r1.16 ssl_scache_dbm.c
--- modules/ssl/ssl_scache_dbm.c	17 May 2002 11:24:17 -0000	1.16
+++ modules/ssl/ssl_scache_dbm.c	17 Sep 2002 11:32:47 -0000
@@ -228,21 +228,25 @@
      * XXX: Should we open the dbm against r->pool so the cleanup will
      * do the apr_dbm_close? This would make the code a bit cleaner.
      */
+    ssl_mutex_on(s);
     if ((rc = apr_dbm_open(&dbm, mc->szSessionCacheDataFile,
 	    APR_DBM_RWCREATE, SSL_DBM_FILE_MODE, mc->pPool)) != APR_SUCCESS)
{
         ap_log_error(APLOG_MARK, APLOG_ERR, rc, s,
                      "Cannot open SSLSessionCache DBM file `%s' for reading
"
                      "(fetch)",
                      mc->szSessionCacheDataFile);
+        ssl_mutex_off(s);
         return NULL;
     }
     rc = apr_dbm_fetch(dbm, dbmkey, &dbmval);
     if (rc != APR_SUCCESS) {
         apr_dbm_close(dbm);
+        ssl_mutex_off(s);
         return NULL;
     }
     if (dbmval.dptr == NULL || dbmval.dsize <= sizeof(time_t)) {
         apr_dbm_close(dbm);
+        ssl_mutex_off(s);
         return NULL;
     }
 
@@ -251,12 +255,14 @@
     ucpData = (UCHAR *)malloc(nData);
     if (ucpData == NULL) {
         apr_dbm_close(dbm);
+        ssl_mutex_off(s);
         return NULL;
     }
     memcpy(ucpData, (char *)dbmval.dptr+sizeof(time_t), nData);
     memcpy(&expiry, dbmval.dptr, sizeof(time_t));
 
     apr_dbm_close(dbm);
+    ssl_mutex_off(s);
 
     /* make sure the stuff is still not expired */
     now = time(NULL);


-------------
cheers, 
amund 

Re: [PATCH] Threadsafety to mod_ssl dbm session cache

Posted by Jeff Trawick <tr...@attglobal.net>.
Amund Elstad <Am...@ergo.no> writes:

> I am reposting a patch posted by Jeff Trawick which adds mutex protection to
> the retrieve operation. Before I applied this patch, I  experienced the
> following problems with 2.0.40 on win32:
> 
> 	- Child process termination (status 3221225477 in error_log,
> segfault?) - often twice or more every weekday. 
> 	- Infinite loops (I traced one to dbm_close:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12705) several times a
> week. 
> 
> I applied the patch on September 17th and the server has been running
> perfectly stable since. There has been no significant change in server load,
> nor any other changes in software or hardware.
> 
> The extra mutex protection is in my experience required on win32 (probably
> needed for other threaded MPMs as well), and IMO should be commited to cvs. 

Thanks for the update (and for diagnosing it in the first place!).  I
kept the patch around but wasn't going to commit until I got some
feedback.  I'll commit it today.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...