On 04/08/2009 08:31 AM, Plüm, Rüdiger, VF-Group wrote: > > >> -----Ursprüngliche Nachricht----- >> Von: Paul Querna >> Gesendet: Dienstag, 7. April 2009 20:15 >> An: [email protected] >> Betreff: Re: segfaults / core dumps caused by >> ap_internal_fast_redirect >> >> On Tue, Apr 7, 2009 at 10:01 AM, William A. Rowe, Jr. >> <[email protected]> wrote: >>> Plüm, Rüdiger, VF-Group wrote: >>> >>>> How to solve? >>>> >>>> I don't know. This is why I write this mail :-). >>> We eliminate internal_fast_redirect ;-) >>> >> hell yeah, I would love to eliminate internal redirects completely. >> > > Not surprised by these answers :-). > But what are the alternatives to internal redirects. AFAIKT > ap_internal_fast_redirect is currently used by mod_dir and > mod_negotiation. So what should they do instead? > Furthermore we also have this crashing risk in 2.2.x as well. > It does not seem to happen there that often because we > do not use eor buckets there and the used APR has the old > pool implementation. We cannot axe it in 2.2.x, but of course > approaches for 2.2.x and trunk can be different.
As I have seen no further proposals in the last 14 days for a replacement of ap_internal_fast_redirect (as said I have no idea either) I would like to fix the current code to avoid the segfaults that are currently occurring. My outlined approach is the following: 1. Create _ex versions of ap_sub_req_lookup_uri / ap_sub_req_lookup_dirent and ap_sub_req_lookup_file that allow to supply a pool from which the subrequest allocates memory. 2. Let ap_internal_fast_redirect spit out a warning to the error log if the subrequest pool is different from the request pool. 3. Fix the current internal consumers of ap_internal_fast_redirect (mod_dir / mod_negotiation to use the _ex versions and feed them with the request pool. Any opinions / objections? Regards Rüdiger
