On 7 November 2013 20:05, Jan Kaluza <jkal...@redhat.com> wrote:
> On 11/07/2013 06:23 PM, Jeff Trawick wrote:
>>
>> On Thu, Nov 7, 2013 at 1:53 AM, Jan Kaluža <jkal...@redhat.com
>> <mailto:jkal...@redhat.com>> wrote:
>>
>> On 11/06/2013 10:38 PM, Steve Hay wrote:
>>
>> On 6 November 2013 18:42, Fred Moyer <f...@redhotpenguin.com
>> <mailto:f...@redhotpenguin.com>> wrote:
>>
>> On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay
>> <steve.m....@googlemail.com
>> <mailto:steve.m....@googlemail.com>> wrote:
>>
>>
>> On 6 November 2013 17:55, Fred Moyer
>> <f...@redhotpenguin.com <mailto:f...@redhotpenguin.com>>
>>
>> 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
there.
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
though.)
I'm struggling to understand the handling of %ENV in both perl and
mod_perl, but running the local_env.pm 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
httpd.exe!
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*
it!)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
