On 04/28/2017 10:50 PM, Jacob Champion wrote: > On 04/27/2017 02:46 AM, Yann Ylavic wrote: >> Jacob, does it work better? > > Unfortunately not; now we have crashes in mod_case_filter. > > If you're having trouble reproducing a crash, try using an APR with pool > debugging enabled. The poisoned-on-free memory > is showing up really nicely. > > I ask again, though... ;D > > ...why does the EOR bucket have memory ownership of a request_rec, especially > when its lifetime is not well defined? And > why have we put business logic into a finalizer? This is ringing all of my > memory management alarm bells.
This dates back to a long time ago (http://svn.apache.org/viewvc?view=revision&revision=327925) when we started to add async processing to httpd. We had the issue that we could not just destroy the request pool, once we "finished" the processing of a request, because we could still have buckets and data created out of the request pool in the async processing of the filters. Hence the idea was to sent a special final request bucket as the very last bucket of a request that tells the filter that consumes the bucket (usually the core output filter) that no data for the request is coming down the filter stack and that it is now save to destroy the request pool. And in order to prevent that logic to be coded in the filter (when it just sees the bucket) it was put in the "finalizer" code of the eor bucket. You might find this strange, but IMHO we have this pattern to use cleanups for some business logic quite often in httpd and we tie a lot of this logic to the lifecycle of pools. So pools are not just a memory management tool, but also a lifecycle management tool. Regards Rüdiger
