On Tue, Dec 13, 2016 at 12:17 AM, Jacob Champion <champio...@gmail.com> wrote: > 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!
BSD::Resource's setrlimit(RLIMIT_CPU, soft, hard)?