On 12/12/2016 03:10 PM, William A Rowe Jr wrote:
On Mon, Dec 12, 2016 at 5:00 PM, Jacob Champion <champio...@gmail.com <mailto: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 <mailto: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?
I would say yes, definitely. Better for us to bring down a tester's machine with a regression and fix the problem before it goes live, than to spare the tester and end up shipping said regression.
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.
Agreed! --Jacob
