perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: httpd24 on Windows?
Date Mon, 04 Nov 2013 15:38:31 GMT
On Mon, Nov 4, 2013 at 8:43 AM, Jeff Trawick <trawick@gmail.com> wrote:

> On Mon, Nov 4, 2013 at 4:22 AM, Steve Hay <steve.m.hay@googlemail.com>wrote:
>
>> On 30 October 2013 18:24, Steve Hay <steve.m.hay@googlemail.com> wrote:
>> > I've now tried other perls (5.16.0, 5.18.0 and 5.19.4) in other build
>> > configurations (with/without PERL_IMPLICIT_SYS) and can confirm that
>> > the crash only occurs with perls built with PERL_IMPLICIT_SYS enabled.
>> > I generally use perl with that disabled (although that isn't the
>> > default configuration), so that's probably what I was doing when I had
>> > this working back in July.
>> >
>> > That is indeed a Windows-specific thing, unfortunately :-/
>> >
>> > I will see what I can do to fix it since most users will indeed have
>> > the default configuration (certainly ActivePerl and Strawberry Perl
>> > both do) and hence experience the crash.
>>
>> As per your suggestion on the other thread, I've now merged the
>> httpd24 and threading branches togther into a new branch called
>> httpd24threading and I'm delighted to see that it does indeed fix the
>> add_config.t crash when PERL_IMPLICIT_SYS is defined :-)
>>
>> There is one oddity when starting up the server: it complains that
>> "KeepAliveTimeout 300" has the wrong format! I don't understand this.
>> The directive is not new and that syntax (number of seconds) has long
>> been valid. httpd-2.3.2 added a new millisecond format (append "ms"),
>> but that shouldn't affect this:
>> http://httpd.apache.org/docs/2.4/mod/core.html#keepalivetimeout
>
>
> The most likely cause would seem to be some stray character after the 300
> (e.g., maybe a ^M on Unix)???  The next most likely (also unlikely) cause
> would seem to be that per-thread errno is hosed in your httpd build for
> some reason???  (yeah, I know how bogus this sounds :) )
>
> 2.2 parses the number via the very forgiving atoi().
> 2.4 parses the number with apr_strtoi64() which manipulates errno and also
> by checking what comes after the number, which also manipulates errno and
> is sensitive to the first character that apr_strtoi64() can't parse
>
> Maybe the quickest way to get to the bottom of it is to add some tracing
> to the three "return some-error" paths in
> server/util.c::ap_timeout_parameter_parse().
>

I should be able to try that out...

What do I need to grab from svn and run, and does this particular error
reproduce on Linux?

>
>
>>
>> Simply deleting that line from
>> t/response/TestDirective/perlcleanuphandler.pm works around it and the
>> test still passes, but I'd rather understand what the problem is.
>>
>> Otherwise, my current test summary report is as follows:
>>
>> Test Summary Report
>> -------------------
>> t\apache\subprocess.t                 (Wstat: 0 Tests: 1 Failed: 0)
>>   Parse errors: Bad plan.  You planned 5 tests but ran 1.
>> t\api\access2_24.t                    (Wstat: 0 Tests: 6 Failed: 3)
>>   Failed tests:  2, 5-6
>> t\compat\conn_rec.t                   (Wstat: 0 Tests: 2 Failed: 0)
>>   Parse errors: Bad plan.  You planned 4 tests but ran 2.
>> t\directive\perlloadmodule2.t         (Wstat: 0 Tests: 3 Failed: 1)
>>   Failed test:  3
>> t\hooks\authen_digest.t               (Wstat: 0 Tests: 7 Failed: 4)
>>   Failed tests:  4-7
>> t\modperl\interpreter.t               (Wstat: 0 Tests: 0 Failed: 0)
>>   Parse errors: Bad plan.  You planned 17 tests but ran 0.
>> t\modperl\local_env.t                 (Wstat: 0 Tests: 6 Failed: 1)
>>   Failed test:  6
>> t\modperl\merge.t                     (Wstat: 0 Tests: 10 Failed: 3)
>>   Failed tests:  3, 6, 9
>> t\modperl\merge2.t                    (Wstat: 0 Tests: 10 Failed: 3)
>>   Failed tests:  3, 6, 9
>> t\modperl\merge3.t                    (Wstat: 0 Tests: 10 Failed: 3)
>>   Failed tests:  3, 6, 9
>> t\modules\cgi.t                       (Wstat: 0 Tests: 5 Failed: 5)
>>   Failed tests:  1-5
>> t\modules\cgi2.t                      (Wstat: 0 Tests: 5 Failed: 5)
>>   Failed tests:  1-5
>> t\modules\cgipost.t                   (Wstat: 0 Tests: 6 Failed: 5)
>>   Failed tests:  2-6
>> t\modules\cgipost2.t                  (Wstat: 0 Tests: 6 Failed: 5)
>>   Failed tests:  2-6
>> t\modules\cgiupload.t                 (Wstat: 0 Tests: 2 Failed: 2)
>>   Failed tests:  1-2
>> t\modules\cgiupload2.t                (Wstat: 0 Tests: 2 Failed: 2)
>>   Failed tests:  1-2
>> t\protocol\echo_block.t               (Wstat: 0 Tests: 3 Failed: 2)
>>   Failed tests:  2-3
>> t\protocol\echo_nonblock.t            (Wstat: 0 Tests: 3 Failed: 1)
>>   Failed test:  2
>> t\protocol\echo_timeout.t             (Wstat: 0 Tests: 5 Failed: 4)
>>   Failed tests:  2-5
>> t\protocol\pseudo_http.t              (Wstat: 0 Tests: 13 Failed: 9)
>>   Failed tests:  3-8, 11-13
>> Files=252, Tests=2484, 815 wallclock secs ( 2.43 usr +  0.53 sys =  2.96
>> CPU)
>> Result: FAIL
>>
>> That's using my own debugging mode builds of perl 5.19.4 and httpd
>> 2.4.4. It also works (with fewer test failures) using 2.2.25.
>>
>> I will try with release mode builds for comparison, and also see how
>> the above list compares with the standard httpd24 branch (using a perl
>> without PERL_IMPLICIT_SYS) to see whether this merged branch has
>> introduced new failures into httpd24.
>>
>> Please could somebody in non-Windows-land give the httpd24threading
>> branch a try and report back what it's looking like there?
>>
>> I think we could be getting close to merging this all into trunk! :-)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>> For additional commands, e-mail: dev-help@perl.apache.org
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message