httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: apr_dbm funkiness...
Date Wed, 07 Nov 2001 02:45:56 GMT
I am thinking the best solution is to not close the dbm until we are completely finished
referencing what we fetch from it. Will submit a patch to ssl_scache_dbm_retrieve() in a
bit.

Bill

> I've discovered an interesting problem with the apr_dbm code (or perhaps how SSL is
using
> it).
>
> Consider the following code from ssl_scache_dbm_retrieve()...
>
> if (apr_dbm_open(&dbm, mc->szSessionCacheDataFile,
>     APR_DBM_RWCREATE, SSL_DBM_FILE_MODE, mc->pPool) != APR_SUCCESS) {
>     ssl_log(s, SSL_LOG_ERROR|SSL_ADD_ERRNO,
>             "Cannot open SSLSessionCache DBM file `%s' for reading (fetch)",
>              mc->szSessionCacheDataFile);
>     ssl_mutex_off(s);
>      return NULL;
> }
> rc = apr_dbm_fetch(dbm, dbmkey, &dbmval);
> apr_dbm_close()
>
> apr_dbm_fetch() returns dbmval which contains a pointer to the char* value associated
with
> the search key. Turns out that this value resides in storage allocated during the
> apr_dbm_open() call.  When apr_dbm_close() is called, the value is no longer valid and
may
> be overwritten.
>
> So, either we need to replicate the value in memory with suitable lifetime scope (where?
> in apr_dbm_fetch? would need to pass in a pool to do this). Or not issue apr_dbm_close
> until we are done using the value.
>
> Thoughts?
>
> Bill
>


Mime
View raw message