httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1773865 - /httpd/httpd/trunk/modules/http/http_filters.c
Date Tue, 13 Dec 2016 00:24:22 GMT
On Dec 12, 2016 6:07 PM, "Yann Ylavic" <ylavic.dev@gmail.com> wrote:

On Tue, Dec 13, 2016 at 12:17 AM, Jacob Champion <champion.p@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 <champion.p@gmail.com
>> <mailto:champion.p@gmail.com>> wrote:
>>
>>     On 12/12/2016 01:23 PM, Yann Ylavic wrote:
>>
>>         On Mon, Dec 12, 2016 at 10:07 PM, Jacob Champion
>>         <champion.p@gmail.com <mailto:champion.p@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.


Not worried about my machine. Hanging a build machine with no feedback
would be an issue

>> 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)?


If portable to Linux/Windows, then mission accomplished.

Mime
View raw message