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 13:43:29 GMT
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().


>
> 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/

Mime
View raw message