On 11/06/2007 11:06 PM, Ruediger Pluem wrote:
>
> On 11/06/2007 10:28 PM, Joe Orton wrote:
>> On Tue, Nov 06, 2007 at 09:45:42PM +0100, Ruediger Pluem wrote:
>>> On 11/06/2007 04:02 PM, [EMAIL PROTECTED] wrote:
> >> Currently I see the danger that the connection level filter ssl_io_filter
>>> is allocated out of the request pool by add_any_filter_handle (because r !=
>>> NULL)
>>> instead of the connection pool. I think that even in the upgrade case the
>>> lifetime of
>>> ssl_io_filter is the same as the (remaining) lifetime of the connection and
>>> that
>>> this lifetime might be longer than that of r->pool.
>> Great catch, I missed that this actually changes the lifetime of the
>> filter, and regret not testing this in my apr-pool-debug build!
>>
>> I would like to say that is an add_any_filter_handle bug, if only
>> because it makes the mod_ssl issue tractable without major surgery on
>> the core filtering design :)
>>
>> If a filter is being added with connection-lifetime it must be allocated
>> out of the c->pool anyway, regardless of whether r is passed in, surely.
>> So, completely untested:
>>
>> Index: server/util_filter.c
>> ===================================================================
>> --- server/util_filter.c (revision 592444)
>> +++ server/util_filter.c (working copy)
>> @@ -279,7 +279,7 @@
>> ap_filter_t **p_filters,
>> ap_filter_t **c_filters)
>> {
>> - apr_pool_t* p = r ? r->pool : c->pool;
>> + apr_pool_t *p = frec->ftype < AP_FTYPE_CONNECTION && r ? r->pool :
>> c->pool;
>> ap_filter_t *f = apr_palloc(p, sizeof(*f));
>> ap_filter_t **outf;
>
> I agree that this should do the trick.
Any reason why this did not get committed so far?
Regards
Rüdiger
