Ruediger Pluem wrote:
>
> On 06/08/2007 04:48 AM, [EMAIL PROTECTED] wrote:
>> Author: pquerna
>> Date: Thu Jun 7 19:48:04 2007
>> New Revision: 545379
....
>> +SSL_SESSION *ssl_scache_mc_retrieve(server_rec *s, UCHAR *id, int idlen)
>> +{
>> + SSL_SESSION *pSession;
>> + MODSSL_D2I_SSL_SESSION_CONST unsigned char *pder;
>> + apr_size_t der_len;
>> + SSLModConfigRec *mc = myModConfig(s);
>> + char buf[MC_KEY_LEN];
>> + char* strkey = NULL;
>> + apr_status_t rv;
>> +
>> + strkey = mc_session_id2sz(id, idlen, buf, sizeof(buf));
>> +
>> + if(!strkey) {
>> + ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
>> + "scache_mc: Key generation borked.");
>> + return NULL;
>> + }
>> +
>> + rv = apr_memcache_getp(memctxt, mc->pPool, strkey,
>
> Is this the correct pool to use? AFAICT the data stored in *pder
> will only be used locally, because d2i_SSL_SESSION allocates
> new memory to create the pSession object.
> mc->pPool seems to be a pool with a long lifetime to me and I fear
> that we introduce a memory leak here. How about a temporary subpool
> if no other pool is at hand here?
No, its not the correct pool to use -- but this is the pool that the DBM
backend uses.... So, ugh. Looks like the dbm backend also leaks :-)
I think the right fix is to change ssl_callback_GetSessionCacheEntry in
ssl_engine_kernel.c, and pass down either the conn_rec* or the conn's
pool. This of course means changing the prototype on
ssl_scache_retrieve and everything it calls... Thoughts?
Should likely do the same with
ssl_callback_NewSessionCacheEntry/ssl_scache_store....
-Paul
