perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: mod_perl head build with httpd 2.4.6 on Linux results
Date Sat, 09 Nov 2013 00:35:17 GMT
On 7 November 2013 20:05, Jan Kaluza <> wrote:
> On 11/07/2013 06:23 PM, Jeff Trawick wrote:
>> On Thu, Nov 7, 2013 at 1:53 AM, Jan Kalu┼ża <
>> <>> wrote:
>>     On 11/06/2013 10:38 PM, Steve Hay wrote:
>>         On 6 November 2013 18:42, Fred Moyer <
>>         <>> wrote:
>>             On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay
>>             <
>>             <>> wrote:
>>                 On 6 November 2013 17:55, Fred Moyer
>>                 < <>>
>>                 wrote:
>>                     Greetings,
>>                     I've been tracking the httpd 2.4 dev work that Steve
>>                     has been merging to
>>                     trunk,
>>                 I haven't merged anything into trunk. I created a new
>>                 branch called
>>                 httpd24threading, copied from httpd24, and then merged
>>                 the threading
>>                 branch into that. I was hoping that it would fix an
>>                 interpreter/threads-related problem that I was having on
>>                 Windows with
>>                 the httpd24 branch, and it does indeed seem to have done.
>>             Clearly I need to pay better attention here... I'll check
>>             out the
>>             httpd24 branch and give that a whirl instead.
>>         Nooo! Check out the httpd24threading branch and give *that* a
>>         whirl!!!
>>         *That*'s the one that I think we should merge into trunk when
>> we're
>>         happy with it, and if I read Jeff's latest post correctly then
>>         things
>>         are better than I thought -- it looks like the Require line
>> parsing
>>         problem isn't actually a problem at all right now, and won't be
>>         until
>>         such time as PerlAddAuthzProvider is updated to allow an
>>         optional 2nd
>>         handler. So I think we can at least punt that issue into the
>> future
>>         for now, and worry about it if/when PerlAddAuthzProvider is
>>         enhanced.
>>     Latest httpd24threading looks OK on Fedora for me. It passes/fails
>>     the same tests as in older "httpd24" branch.
>>     cgi,t related failures are caused by r1491887 (Pointed that already
>>     in some older mail to this mailing list). compat/conn_rec.t is
>>     caused by client_addr vs. remote_addr I was not able to fix in
>>     httpd24 branch.
>> Is this the complete set?  (cgi.t, conn_rec.t?)  I'd like to compare
>> what others are seeing with my Windows results.
> On Fedora 19 with httpd-2.4 and httpd24threading branch I get only following
> failing tests:
> t/compat/conn_rec.t                   (Wstat: 0 Tests: 2 Failed: 0)
>   Parse errors: Bad plan.  You planned 4 tests but ran 2.
> t/modules/cgi.t                       (Wstat: 0 Tests: 5 Failed: 2)
>   Failed tests:  2, 5
> t/modules/cgi2.t                      (Wstat: 0 Tests: 5 Failed: 1)
>   Failed test:  3
> t/modules/cgipost.t                   (Wstat: 0 Tests: 6 Failed: 1)
>   Failed test:  4
> t/modules/cgipost2.t                  (Wstat: 0 Tests: 6 Failed: 1)
>   Failed test:  4
> t/modules/cgiupload.t                 (Wstat: 0 Tests: 2 Failed: 1)
>   Failed test:  1
> t/modules/cgiupload2.t                (Wstat: 0 Tests: 2 Failed: 1)
>   Failed test:  2
> If I remember well, conn_rec.t is broken because of remote_ip/remote_addr
> changes which I was not able to fix in the way where it would work with both
> httpd-2.2 and httpd-2.4. I would vote to stop shipping this compat code once
> we updated to 2.4.
> All cgi*.t tests fails since commit r1491887.

r1491887 restored the running of the tests in t/modperl/local_env.t,
which itself fails for me on Windows. I've been looking at why, but
can't quite figure it out.

All but the last test pass. The last test checks that a copy of %ENV
taken before making local()ized changes to it matches the restored
%ENV after the local() scope has been exited. It fails because %ENV
has one more item in it than it did originally. The original had a key
named 'SystemRoot'; the restored version has that and another key
named 'SYSTEMROOT' too. On Windows, environment variable names (like
file names and registry keys and many other things) are
case-preserving but case-insensitive; clearly something has gone amiss

The extra key creeps in within t_cmp(): it isn't there before

    t_debug("expected: " . struct_as_string(0, $expected));

but is there after it! Inside struct_as_string() we mistakenly go into
the !HAS_DUMPER code path due to a wrong test for perl >= 5.6.0 [which
I've just fixed in r1540227] and do this:

            my @data = ();
            for my $key (keys %{ $_[0] }) {
                push @data,
                    "$key => " .
                    struct_as_string($level+1, $_[0]->{$key});
            return join "\n", "{", map({"$pad$_,"} @data), "$spad\}";

which looks perfectly reasonable but wrongly causes the extra key to
appear in %ENV. (Perhaps it gets SystemRoot from keys() but that gets
uppercased when looking up the value a few lines later, causing the
SYSTEMROOT key to be auto-vivified? I haven't checked that theory yet

I'm struggling to understand the handling of %ENV in both perl and
mod_perl, but running the code outside of the mod_perl
environment I can't reproduce the problem, so it seems like something
in mod_perl, perhaps in modperl_env.c, that is at fault.

Is it missing the "magic" that perl has to effect the
case-insensitivity? I notice that there are three uses of #ifdef
MP_PERL_HV_GMAGICAL_AWARE in this file, but the symbols is not
#defined anywhere. I tried #defining it, but now the test crashes

Does anyone know what that #define is all about, or have any other
insights into this?

(Note: The test will start passing on Windows when mod_perl is updated
to include r1540227 because that change makes struct_as_string() use
Data::Dumper, which doesn't trigger this problem with %ENV. That will
just be masking the problem, though; I'd obviously still like to *fix*

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message