On Mon, Dec 12, 2016 at 5:00 PM, Jacob Champion <champio...@gmail.com> wrote:
> On 12/12/2016 01:23 PM, Yann Ylavic wrote: > >> On Mon, Dec 12, 2016 at 10:07 PM, Jacob Champion <champio...@gmail.com> >> wrote: >> >> >>> What's the case where this catches recursion that the previous logic in >>> r1773861 did not handle? I'm trying to write a test that fails on >>> r1773861 >>> and succeeds on r1773865, but I haven't figured it out yet. >>> >> >> I think it's more r1773862 that fixes your test case. >> > > To clarify: I can't reproduce any problems with r1773861 in the first > place, even with ErrorDocument. I agree that r1773862 (and r1773865) work > for me; I just don't know what makes them functionally different. In my > attempted test cases, I can't find any case where the rr->pool used during > the internal redirect differs from the original r->pool. > > Can you send me a config snippet that reproduces the loop with > ErrorDocument? I'm not arguing against your followup patches; I just want > to make sure a correct test case gets into the suite. :D Speaking of the test suite behavior, your mission had succeeded. My quad core machine was pegged, X-Windows/Gnome unresponsive. Do we want to put such tests in the framework? If any of our perl gurus have a good suggestion to throttle the top limit of cpu/time consumed, that would be a good enhancement to the framework.
