You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2004/05/24 17:22:56 UTC

apr/pool makes compat/send_fd & driective/setupenv fail on Win32

As I reported recently, compat/send_fd.t and directive/setupenv.t both 
currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32, 
but work when tried in isolation.

After a little trial & error, I've found that running apr/pool.t before 
them make them fail, i.e.

    perl t/TEST compat/send_fd
    perl t/TEST directive/setupenv

both run OK, but

    perl t/TEST apr/pool compat/send_fd
    perl t/TEST apr/pool directive/setupenv

both fail (apr/pool.t itself runs OK, though).

In each case there is nothing useful in the error log.  The console 
output is as follows:

t/compat/send_fd....response had protocol HTTP/0.9 (headers not sent?) 
at t/compat/send_fd.t line 15
t/compat/send_fd....dubious
        Test returned status 9 (wstat 2304, 0x900)
DIED. FAILED tests 1-3

t/directive/setupenv....response had protocol HTTP/0.9 (headers not 
sent?) at t/directive/setupenv.t line 12
t/directive/setupenv....dubious
        Test returned status 9 (wstat 2304, 0x900)
DIED. FAILED tests 1-3

Any ideas where to start looking for the cause of this?  Would any 
MOD_PERL_TRACE flags help?

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: t/SMOKE not working properly? [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> With this patch in place, t/SMOKE now works a treat:
> 
> =====
> [warning] [001-00-00] trying all tests 10 times
> [  error] recorded a positive failure ('t\compat\send_fd.t'), will try 
> to minimize the input now
> [warning] [001-01-01] trying 't\compat\send_fd.t' on its own
> [warning]
> [001-02-01] trying 12 tests
> [  error] *** reduction 2 succeeded (12 tests) ***
> [warning]
> [001-03-01] trying 6 tests
> [warning]
> [001-03-02] trying 6 tests
> [  error] *** reduction 3 succeeded (6 tests) ***
> [warning]
> [001-04-01] trying 3 tests
> [warning]
> [001-04-02] trying 3 tests
> [  error] *** reduction 4 succeeded (3 tests) ***
> [warning]
> [001-05-01] trying 2 tests
> [  error] *** reduction 5 succeeded (2 tests) ***
> [warning]
> [001-06-01] trying 1 tests
> [warning]
> [001-06-02] trying 1 tests
> [  error] *** reduction 6 succeeded (1 tests) ***
> iteration 1 (2 tests):
>         C:\apache2\perl5\bin\perl.exe C:/Temp/modperl-2.0/t/TEST 
> t\apr\pool.t t\compat\send_fd.t
> (made 6 successful reductions)

Nice :)

Thanks for the research and the patch, Steve, no committed!

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


[PATCH] Re: t/SMOKE not working properly? [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>Steve Hay wrote:
>[...]
>  
>
>>>That what t/SMOKE is for. It does the job of finding such sequences for you.
>>>
>>>      
>>>
>>I'd forgotten about that, but now that I come to try it (to see if it 
>>finds the correct result, now that I know what the correct result is 
>>:-), it seems to not work properly.
>>    
>>
>
>I have never tried running it on windows, it's quite possible that it doesn't 
>work there. But I remember that Randy was successful running it. That's why we 
>changed it to use IPC::Run. If we can fix it that would be good.
>
I remember the IPC::Run3 stuff myself; it definitely *did* do something 
useful on Win32 at the time.

>
>  
>
>>I know that the failure sequence lies in apr/ and compat/ so I ran "perl 
>>t/SMOKE apr compat".
>>
>>The first time I tried it did this:
>>
>>=====
>>[warning] Using random number seed: 1148777795 (autogenerated)
>>[   info] Report file: 
>>C:\Temp\mod_perl-1.99_14\smoke-report-Tue_May_25_08-59-19_2004.txt
>>[warning]
>>------------------------------------------------------------
>>[warning] [001-00-00] trying all tests 10 times
>>[  error] recorded a positive failure ('t\compat/conn_authen.t'), will 
>>try to minimize the input now
>>[warning] [001-01-01] trying 't\compat/conn_authen.t' on its own
>>iteration 1 (1 tests):
>>        C:\apache2\perl5\bin\perl.exe C:/Temp/mod_perl-1.99_14/t/TEST 
>>t\compat/conn_authen.t
>>(made 1 successful reductions)
>>=====
>>
>>What does "positive failure" mean?  Why does it stop there? - does it 
>>think there is a problem with compat/conn_authen?  
>>    
>>
>
>The logic is explained in the module's docs. If it finds a test that fails on 
>its own, there is no point to run smoke, since it'll always fails on that 
>test. So it doesn't to make your CPU's life shorter.
>
Right, so it's thinking that a test failed when it (almost certainly) 
didn't.

>
>  
>
>>There doesn't seem to 
>>be when I run it manually, even running it after apr/pool.
>>
>>I tried another two times and the output each time was exactly as above, 
>>except that it picked a different test each time to complain about -- 
>>compat/request_body then compat/request, neither of which seem to have 
>>any trouble that I'm aware of either.
>>    
>>
>
>Perhaps on windows it thinks that a test fails when it doesn't. It just parses 
>the output of Test::Harness and looks for 'ok' and fails otherwise. You can run:
>
>   t/SMOKE -v ...
>
>to get the verbose output of what it does. (it's different from -v in the 
>t/TEST land).
>
Ah, yes - it's all coming back to me now.  I haven't tried this for a 
while.  Here's some typical output with -v:

=====
C:\Temp\modperl-2.0>perl t/SMOKE -v apr compat
[warning] Using random number seed: 1178930015 (autogenerated)
[   info] Report file: 
C:\Temp\modperl-2.0\smoke-report-Tue_May_25_09-41-23_2004.txt
[warning]
------------------------------------------------------------
[warning] [001-00-00] trying all tests 10 times
t\compat/apache........FAILED
[  error] ------------------------------------------------------------
[  error]               *** run log ***
    [  error] unknown opts or test names: t\compat/apache.t
    -help will list options


[  error] ------------------------------------------------------------
[  error] recorded a positive failure ('t\compat/apache.t'), will try to 
minimize the input now
[warning] [001-01-01] trying 't\compat/apache.t' on its own
t\compat/apache..FAILED
[  error] ------------------------------------------------------------
[  error]               *** run log ***
    [  error] unknown opts or test names: t\compat/apache.t
    -help will list options


[  error] ------------------------------------------------------------
iteration 1 (1 tests):
        C:\apache2\perl5\bin\perl.exe C:/Temp/modperl-2.0/t/TEST 
-verbose t\compat/apache.t
(made 1 successful reductions)
=====

So it appears to not even try the test because it doesn't like the test 
name argument "t\compat/apache.t".  This is quite reproducible: "perl 
t/TEST t\compat/apache.t" produces the same complaint as seen above.

I guess the mess of backslashes and forward slashes should really be 
cleaned up, but t/TEST should also probably be tolerant of it, just in 
case -- perl.exe itself is quite happy when given such a path.

I've had a look at Apache::TestRun::split_test_args().

When running "perl t/TEST t/compat/apache.t", the line

        $arg =~ s@^(?:\./)?t/@@;

removes the leading "t/" so that the $file which is subsequently tested 
for is "C:\Temp\modperl-2.0\t\compat\apache.t" (catfile runs its return 
values through canonpath, hence the /'s have become \'s), which is 
correctly identified as a test and added to @tests.

But when running "perl t/TEST t\compat/apache.t" the above s/// fails to 
remove the leading "t\".  The $file tested for is then 
"C:\Temp\modperl-2.0\t\t\compat\apache.t", which doesn't exist, so 
nothing gets added to @tests, and the t\compat/apache.t argument gets 
thrown into @leftovers instead.

The attached patch allows for t\ and .\t\ at the start of the test name, 
and also makes sure that the paths finally placed in $self->{tests} are 
nicely cleaned up.

With this patch in place, t/SMOKE now works a treat:

=====
[warning] [001-00-00] trying all tests 10 times
[  error] recorded a positive failure ('t\compat\send_fd.t'), will try 
to minimize the input now
[warning] [001-01-01] trying 't\compat\send_fd.t' on its own
[warning]
[001-02-01] trying 12 tests
[  error] *** reduction 2 succeeded (12 tests) ***
[warning]
[001-03-01] trying 6 tests
[warning]
[001-03-02] trying 6 tests
[  error] *** reduction 3 succeeded (6 tests) ***
[warning]
[001-04-01] trying 3 tests
[warning]
[001-04-02] trying 3 tests
[  error] *** reduction 4 succeeded (3 tests) ***
[warning]
[001-05-01] trying 2 tests
[  error] *** reduction 5 succeeded (2 tests) ***
[warning]
[001-06-01] trying 1 tests
[warning]
[001-06-02] trying 1 tests
[  error] *** reduction 6 succeeded (1 tests) ***
iteration 1 (2 tests):
        C:\apache2\perl5\bin\perl.exe C:/Temp/modperl-2.0/t/TEST 
t\apr\pool.t t\compat\send_fd.t
(made 6 successful reductions)
=====

- Steve


------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

Re: t/SMOKE not working properly? [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
>>That what t/SMOKE is for. It does the job of finding such sequences for you.
>>
> 
> I'd forgotten about that, but now that I come to try it (to see if it 
> finds the correct result, now that I know what the correct result is 
> :-), it seems to not work properly.

I have never tried running it on windows, it's quite possible that it doesn't 
work there. But I remember that Randy was successful running it. That's why we 
changed it to use IPC::Run. If we can fix it that would be good.

> I know that the failure sequence lies in apr/ and compat/ so I ran "perl 
> t/SMOKE apr compat".
> 
> The first time I tried it did this:
> 
> =====
> [warning] Using random number seed: 1148777795 (autogenerated)
> [   info] Report file: 
> C:\Temp\mod_perl-1.99_14\smoke-report-Tue_May_25_08-59-19_2004.txt
> [warning]
> ------------------------------------------------------------
> [warning] [001-00-00] trying all tests 10 times
> [  error] recorded a positive failure ('t\compat/conn_authen.t'), will 
> try to minimize the input now
> [warning] [001-01-01] trying 't\compat/conn_authen.t' on its own
> iteration 1 (1 tests):
>         C:\apache2\perl5\bin\perl.exe C:/Temp/mod_perl-1.99_14/t/TEST 
> t\compat/conn_authen.t
> (made 1 successful reductions)
> =====
> 
> What does "positive failure" mean?  Why does it stop there? - does it 
> think there is a problem with compat/conn_authen?  

The logic is explained in the module's docs. If it finds a test that fails on 
its own, there is no point to run smoke, since it'll always fails on that 
test. So it doesn't to make your CPU's life shorter.

> There doesn't seem to 
> be when I run it manually, even running it after apr/pool.
> 
> I tried another two times and the output each time was exactly as above, 
> except that it picked a different test each time to complain about -- 
> compat/request_body then compat/request, neither of which seem to have 
> any trouble that I'm aware of either.

Perhaps on windows it thinks that a test fails when it doesn't. It just parses 
the output of Test::Harness and looks for 'ok' and fails otherwise. You can run:

   t/SMOKE -v ...

to get the verbose output of what it does. (it's different from -v in the 
t/TEST land).

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


t/SMOKE not working properly? [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>Steve Hay wrote:
>  
>
>>As I reported recently, compat/send_fd.t and directive/setupenv.t both 
>>currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32, 
>>but work when tried in isolation.
>>
>>After a little trial & error, I've found that running apr/pool.t before 
>>them make them fail
>>    
>>
>
>That what t/SMOKE is for. It does the job of finding such sequences for you.
>
I'd forgotten about that, but now that I come to try it (to see if it 
finds the correct result, now that I know what the correct result is 
:-), it seems to not work properly.

I know that the failure sequence lies in apr/ and compat/ so I ran "perl 
t/SMOKE apr compat".

The first time I tried it did this:

=====
[warning] Using random number seed: 1148777795 (autogenerated)
[   info] Report file: 
C:\Temp\mod_perl-1.99_14\smoke-report-Tue_May_25_08-59-19_2004.txt
[warning]
------------------------------------------------------------
[warning] [001-00-00] trying all tests 10 times
[  error] recorded a positive failure ('t\compat/conn_authen.t'), will 
try to minimize the input now
[warning] [001-01-01] trying 't\compat/conn_authen.t' on its own
iteration 1 (1 tests):
        C:\apache2\perl5\bin\perl.exe C:/Temp/mod_perl-1.99_14/t/TEST 
t\compat/conn_authen.t
(made 1 successful reductions)
=====

What does "positive failure" mean?  Why does it stop there? - does it 
think there is a problem with compat/conn_authen?  There doesn't seem to 
be when I run it manually, even running it after apr/pool.

I tried another two times and the output each time was exactly as above, 
except that it picked a different test each time to complain about -- 
compat/request_body then compat/request, neither of which seem to have 
any trouble that I'm aware of either.

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> As I reported recently, compat/send_fd.t and directive/setupenv.t both 
> currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32, 
> but work when tried in isolation.
> 
> After a little trial & error, I've found that running apr/pool.t before 
> them make them fail

That what t/SMOKE is for. It does the job of finding such sequences for you.

> , i.e.
> 
>     perl t/TEST compat/send_fd
>     perl t/TEST directive/setupenv
> 
> both run OK, but
> 
>     perl t/TEST apr/pool compat/send_fd
>     perl t/TEST apr/pool directive/setupenv
> 
> both fail (apr/pool.t itself runs OK, though).

Does this patch make any difference?

Index: t/response/TestAPR/pool.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/pool.pm,v
retrieving revision 1.12
diff -u -r1.12 pool.pm
--- t/response/TestAPR/pool.pm  14 May 2004 07:58:21 -0000      1.12
+++ t/response/TestAPR/pool.pm  24 May 2004 18:32:13 -0000
@@ -377,16 +377,16 @@
      # errors. They are logged though. So as usual, one has to always
      # watch error_log (things like CGI::Carp's fatalsToBrowser) won't
      # quite be able to catch those.
-    {
-        my $p = APR::Pool->new;
-        t_server_log_error_is_expected();
-        $p->cleanup_register('some_bogus_non_existing', 1);
-    }
-    {
-        my $p = APR::Pool->new;
-        t_server_log_error_is_expected();
-        $p->cleanup_register(\&non_existing1, 1);
-    }
+#    {
+#        my $p = APR::Pool->new;
+#        t_server_log_error_is_expected();
+#        $p->cleanup_register('some_bogus_non_existing', 1);
+#    }
+#    {
+#        my $p = APR::Pool->new;
+#        t_server_log_error_is_expected();
+#        $p->cleanup_register(\&non_existing1, 1);
+#    }

      ### $p->clear ###
      {

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>>I will report the SHA1 problem to the apr-dev list.
>>    
>>
>
>apparently it was added post 2.0.49, I've adjusted the test. Is that OK now?
>
Yes.  Thanks, Stas!

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
> I will report the SHA1 problem to the apr-dev list.

apparently it was added post 2.0.49, I've adjusted the test. Is that OK now?


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
> 
> 
>>Steve, please try the current cvs for this test. Win32 is now skipped for 
>>crypt, but I added sha1 and md5 sub-tests. Got the hashes from htpasswd. Thanks.
>>
> 
> Still not quite right:
> 
> t\apr\util....1..4
> # Running under perl version 5.008004 for MSWin32
> # Current time local: Thu May 27 09:31:31 2004
> # Current time GMT:   Thu May 27 08:31:31 2004
> # Using Test.pm version 1.24
> ok 1
> # crypt
> # crypt is not supported on MSWin32
> ok 2
> # sha1
> not ok 3
> # md5
> ok 4
> FAILED test 3
> 
> This is really weird - it looks like SHA-1 is failing, but running 
> htpasswd on my machine (using the same Apache 2.0.49 as mp2 is using) it 
> seems to be MD5 that disagrees with the values in the test file.
> 
> The test file contains this:
> 
>     md5   => '$apr1$Kld6H/..$o5OPPPWslI3zB20S54u9s1',
>     sha1  => '{SHA}A5NpTRa4TethLkfOYlK9NfDYbAY=',
> 
> Running
> 
>     C:\apache2\bin>.\htpasswd -nbs user "this is some text"
> 
> outputs
> 
>     user:{SHA}A5NpTRa4TethLkfOYlK9NfDYbAY=
> 
> which looks fine, but changing the -nbs to -nbm disagrees with the test 
> file data, and doesn't even give the same answer every time:
> 
>     C:\apache2\bin>.\htpasswd -nbm user "this is some text"
>     user:$apr1$/b......$jr0lO2qReuruvVOd4T/eO.
>     C:\apache2\bin>.\htpasswd -nbm user "this is some text"
>     user:$apr1$6b......$6u//KfKBjzrGboSSY2HiN/
>     C:\apache2\bin>.\htpasswd -nbm user "this is some text"
>     user:$apr1$Fb......$b1RNgyEDm0TTIswEvh3ZY1
> 
> Is this what you'd expect???

I don't expect anything. I just know that neither sha1 nor md5 are tested by 
apr itself.

I don't know why md5 checksum is getting randomized. I think they are using a 
seed to make it different every time, like crypt() does.

I will report the SHA1 problem to the apr-dev list.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>Steve, please try the current cvs for this test. Win32 is now skipped for 
>crypt, but I added sha1 and md5 sub-tests. Got the hashes from htpasswd. Thanks.
>
Still not quite right:

t\apr\util....1..4
# Running under perl version 5.008004 for MSWin32
# Current time local: Thu May 27 09:31:31 2004
# Current time GMT:   Thu May 27 08:31:31 2004
# Using Test.pm version 1.24
ok 1
# crypt
# crypt is not supported on MSWin32
ok 2
# sha1
not ok 3
# md5
ok 4
FAILED test 3

This is really weird - it looks like SHA-1 is failing, but running 
htpasswd on my machine (using the same Apache 2.0.49 as mp2 is using) it 
seems to be MD5 that disagrees with the values in the test file.

The test file contains this:

    md5   => '$apr1$Kld6H/..$o5OPPPWslI3zB20S54u9s1',
    sha1  => '{SHA}A5NpTRa4TethLkfOYlK9NfDYbAY=',

Running

    C:\apache2\bin>.\htpasswd -nbs user "this is some text"

outputs

    user:{SHA}A5NpTRa4TethLkfOYlK9NfDYbAY=

which looks fine, but changing the -nbs to -nbm disagrees with the test 
file data, and doesn't even give the same answer every time:

    C:\apache2\bin>.\htpasswd -nbm user "this is some text"
    user:$apr1$/b......$jr0lO2qReuruvVOd4T/eO.
    C:\apache2\bin>.\htpasswd -nbm user "this is some text"
    user:$apr1$6b......$6u//KfKBjzrGboSSY2HiN/
    C:\apache2\bin>.\htpasswd -nbm user "this is some text"
    user:$apr1$Fb......$b1RNgyEDm0TTIswEvh3ZY1

Is this what you'd expect???

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
Steve, please try the current cvs for this test. Win32 is now skipped for 
crypt, but I added sha1 and md5 sub-tests. Got the hashes from htpasswd. Thanks.

>> (Or: see if the APR C library maintainers would be interested in 
>> adding the fcrypt() that Perl uses to provide crypt() on Win32?) 

> That's a good idea.

They said no. They aren't interested in supporting it.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
> 
> 
>>Steve Hay wrote:
>> 
>>
>>
>>>Stas Bekman wrote:
>>>
>>>
>>>   
>>>
>>>
>>>>Can you take a look at apr_password_validate and see why it doesn't validate 
>>>>on windows?
>>>>
>>>>     
>>>>
>>>
>>>Doh! -- it contains this:
>>>
>>>#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
>>>       apr_cpystrn(sample, passwd, sizeof(sample) - 1);
>>>#elif...
>>>   
>>>
>>
>>Hmm, what's the point of having APR function which doesn't work crossplatform?
>>
> 
> Well apr_password_validate() actually kicks off like this:
> 
>     if (!strncmp(hash, apr1_id, strlen(apr1_id))) {
>         /*
>          * The hash was created using our custom algorithm.
>          */
>         apr_md5_encode(passwd, hash, sample, sizeof(sample));
>     }
>     else {
>         /*
>          * It's not our algorithm, so feed it to crypt() if possible.
>          */
> #if defined(WIN32) || defined(BEOS) || defined(NETWARE)
>         apr_cpystrn(sample, passwd, sizeof(sample) - 1);
> #else
>         ... do stuff using crypt ...
> 
> so it's only the case where "it's not our algorithm" in which the 
> password gets crypted at all, but copied rather than crypted on Win32 
> (no doubt because Win32 doesn't have a native crypt() function -- Perl 
> only has crypt() on Win32 by default since 5.8.1 when an fcrypt() 
> implementation was added to the Perl source to provide it.)

So literally we can only use that function for apr_md5_encoded comparisons. 
I'd rather not call it password_validate.

>>Do we want to support it at all?
>>
> 
> Maybe, since the apr_md5_encode() does look to be portable, but it would 
> be most useful if apr_md5_encode() was supported in the Perl glue too so 
> that apr m5 hashes can be produced in the first place.

What do we need it for? (besides the test?)

>>>so the below patch makes it pass on Win32.  
>>>   
>>>
>>
>>More like hiding the problem, IMHO. Making a test pass is easy, the question 
>>is whether it actually tests something.
>>
> 
> What problem?  It tests what the function does!  The question is whether 
> the function actually does something useful :)

No, there is a problem. What I meant is that the test makes a special case for 
win32, hiding the problem, that this API is not crossplatform and may be 
shouldn't be supported at all.

> Which is correct given that the function simply calls apr_cpystrn() on 
> Win32, isn't it?

Again, if mp2 gives you the API people will use it in their apps. Then things 
won't work on certain platforms. They will come complaining. We'd rather not 
support such APIs in first place.

> So I think we should (a) support apr_md5_encode() and (b) add a note to 
> the APR::Util::password_validate() docs that whilst it is possible to 
> call crypt() in Perl on Win32 (at least as of 5.8.1), 
> password_validate() doesn't support that format of smashed password on 
> Win32 because of limitations in the APR C library.

as suggested above, it is no longer password_validate() then. but rather 
apr_md5_validate

> (Or: see if the APR C library maintainers would be interested in adding 
> the fcrypt() that Perl uses to provide crypt() on Win32?)

That's a good idea.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>Steve Hay wrote:
>  
>
>>Stas Bekman wrote:
>>
>>
>>    
>>
>>>Can you take a look at apr_password_validate and see why it doesn't validate 
>>>on windows?
>>>
>>>      
>>>
>>Doh! -- it contains this:
>>
>>#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
>>        apr_cpystrn(sample, passwd, sizeof(sample) - 1);
>>#elif...
>>    
>>
>
>Hmm, what's the point of having APR function which doesn't work crossplatform?
>
Well apr_password_validate() actually kicks off like this:

    if (!strncmp(hash, apr1_id, strlen(apr1_id))) {
        /*
         * The hash was created using our custom algorithm.
         */
        apr_md5_encode(passwd, hash, sample, sizeof(sample));
    }
    else {
        /*
         * It's not our algorithm, so feed it to crypt() if possible.
         */
#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
        apr_cpystrn(sample, passwd, sizeof(sample) - 1);
#else
        ... do stuff using crypt ...

so it's only the case where "it's not our algorithm" in which the 
password gets crypted at all, but copied rather than crypted on Win32 
(no doubt because Win32 doesn't have a native crypt() function -- Perl 
only has crypt() on Win32 by default since 5.8.1 when an fcrypt() 
implementation was added to the Perl source to provide it.)

>Do we want to support it at all?
>
Maybe, since the apr_md5_encode() does look to be portable, but it would 
be most useful if apr_md5_encode() was supported in the Perl glue too so 
that apr m5 hashes can be produced in the first place.

>
>  
>
>>so the below patch makes it pass on Win32.  
>>    
>>
>
>More like hiding the problem, IMHO. Making a test pass is easy, the question 
>is whether it actually tests something.
>
What problem?  It tests what the function does!  The question is whether 
the function actually does something useful :)

>
>  
>
>>Is mp2 supported on BeOS /  NetWare?
>>    
>>
>
>I have no clue. In theory it should run on all platforms Apache and Perl are 
>supported, but I don't remember anybody reporting any successes or failures on 
>those platforms.
>
>
>  
>
>>Index: t/response/TestAPR/util.pm
>>===================================================================
>>RCS file: /home/cvspublic/modperl-2.0/t/response/TestAPR/util.pm,v
>>retrieving revision 1.8
>>diff -u -r1.8 util.pm
>>--- t/response/TestAPR/util.pm  22 May 2004 21:47:32 -0000      1.8
>>+++ t/response/TestAPR/util.pm  25 May 2004 10:19:32 -0000
>>@@ -23,7 +23,7 @@
>>     ok ! APR::Util::password_validate("one", "two");
>>
>>     my $clear = "pass1";
>>-    my $hash  = "1fWDc9QWYCWrQ";
>>+    my $hash = $^O =~ /MSWin32/ ? $clear : "1fWDc9QWYCWrQ";
>>     ok APR::Util::password_validate($clear, $hash);
>>    
>>
>
>That's comparing clear text to clear text, isn't it?
>
Which is correct given that the function simply calls apr_cpystrn() on 
Win32, isn't it?

So I think we should (a) support apr_md5_encode() and (b) add a note to 
the APR::Util::password_validate() docs that whilst it is possible to 
call crypt() in Perl on Win32 (at least as of 5.8.1), 
password_validate() doesn't support that format of smashed password on 
Win32 because of limitations in the APR C library.

(Or: see if the APR C library maintainers would be interested in adding 
the fcrypt() that Perl uses to provide crypt() on Win32?)

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
> 
> 
>>Can you take a look at apr_password_validate and see why it doesn't validate 
>>on windows?
>>
> 
> Doh! -- it contains this:
> 
> #if defined(WIN32) || defined(BEOS) || defined(NETWARE)
>         apr_cpystrn(sample, passwd, sizeof(sample) - 1);
> #elif...

Hmm, what's the point of having APR function which doesn't work crossplatform?
Do we want to support it at all?

> so the below patch makes it pass on Win32.  

More like hiding the problem, IMHO. Making a test pass is easy, the question 
is whether it actually tests something.

>Is mp2 supported on BeOS /  NetWare?

I have no clue. In theory it should run on all platforms Apache and Perl are 
supported, but I don't remember anybody reporting any successes or failures on 
those platforms.


> Index: t/response/TestAPR/util.pm
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/t/response/TestAPR/util.pm,v
> retrieving revision 1.8
> diff -u -r1.8 util.pm
> --- t/response/TestAPR/util.pm  22 May 2004 21:47:32 -0000      1.8
> +++ t/response/TestAPR/util.pm  25 May 2004 10:19:32 -0000
> @@ -23,7 +23,7 @@
>      ok ! APR::Util::password_validate("one", "two");
> 
>      my $clear = "pass1";
> -    my $hash  = "1fWDc9QWYCWrQ";
> +    my $hash = $^O =~ /MSWin32/ ? $clear : "1fWDc9QWYCWrQ";
>      ok APR::Util::password_validate($clear, $hash);

That's comparing clear text to clear text, isn't it?

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


[PATCH] Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>
>Can you take a look at apr_password_validate and see why it doesn't validate 
>on windows?
>
Doh! -- it contains this:

#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
        apr_cpystrn(sample, passwd, sizeof(sample) - 1);
#elif...

so the below patch makes it pass on Win32.  Is mp2 supported on BeOS / 
NetWare?

- Steve

Index: t/response/TestAPR/util.pm
===================================================================
RCS file: /home/cvspublic/modperl-2.0/t/response/TestAPR/util.pm,v
retrieving revision 1.8
diff -u -r1.8 util.pm
--- t/response/TestAPR/util.pm  22 May 2004 21:47:32 -0000      1.8
+++ t/response/TestAPR/util.pm  25 May 2004 10:19:32 -0000
@@ -23,7 +23,7 @@
     ok ! APR::Util::password_validate("one", "two");

     my $clear = "pass1";
-    my $hash  = "1fWDc9QWYCWrQ";
+    my $hash = $^O =~ /MSWin32/ ? $clear : "1fWDc9QWYCWrQ";
     ok APR::Util::password_validate($clear, $hash);

     Apache::OK;




------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
> 
> 
>>Steve Hay wrote:
>> 
>>
>>
>>>and I now have two other tests (apr/util and modperl/exit) 
>>>failing too (on their own, that is, not just after apr/pool).
>>>   
>>>
>>
>>What do you mean 'now', there weren't failing yesterday and started to fail now?
>>
> 
> Yes -- they work in 1.99_14, but not using the CVS that I just grabbed

OK, let's figure it out. I've committed many new tests since the release.

>>Index: t/response/TestAPR/util.pm
>>===================================================================
>>RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/util.pm,v
>>retrieving revision 1.8
>>diff -u -r1.8 util.pm
>>--- t/response/TestAPR/util.pm  22 May 2004 21:47:32 -0000      1.8
>>+++ t/response/TestAPR/util.pm  25 May 2004 08:16:52 -0000
>>@@ -23,7 +23,7 @@
>>     ok ! APR::Util::password_validate("one", "two");
>>
>>     my $clear = "pass1";
>>-    my $hash  = "1fWDc9QWYCWrQ";
>>+    my $hash  = crypt $clear, 'FE';
>>     ok APR::Util::password_validate($clear, $hash);
>>
>>     Apache::OK;
>>
>>Does this make any difference?
>>
> 
> No, although the hardcoded hash is different to what crypt() returns in 
> my Perl:
> 
> C:\Temp\modperl-2.0>perl -e "print crypt 'pass1', 'FE'"
> FExG070GemhK6

Can you take a look at apr_password_validate and see why it doesn't validate 
on windows?

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


apr/util failure [was Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32]

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>Steve Hay wrote:
>  
>
>>and I now have two other tests (apr/util and modperl/exit) 
>>failing too (on their own, that is, not just after apr/pool).
>>    
>>
>
>What do you mean 'now', there weren't failing yesterday and started to fail now?
>
Yes -- they work in 1.99_14, but not using the CVS that I just grabbed

>
>The common things for some of these tests is that they use methods that throw 
>exceptions. But it could be something else.
>
>apr/util is not one of them, and it uses a very simple XS wrapper. Though this 
>is what I've added recently:
>
>     my $clear = "pass1";
>     my $hash  = "1fWDc9QWYCWrQ";
>     ok APR::Util::password_validate($clear, $hash);
>
>it's quite possible that this doesn't work on windows. It really does crypt. 
>Try replacing hardcoded hash of the password with crypt:
>
>
>Index: t/response/TestAPR/util.pm
>===================================================================
>RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/util.pm,v
>retrieving revision 1.8
>diff -u -r1.8 util.pm
>--- t/response/TestAPR/util.pm  22 May 2004 21:47:32 -0000      1.8
>+++ t/response/TestAPR/util.pm  25 May 2004 08:16:52 -0000
>@@ -23,7 +23,7 @@
>      ok ! APR::Util::password_validate("one", "two");
>
>      my $clear = "pass1";
>-    my $hash  = "1fWDc9QWYCWrQ";
>+    my $hash  = crypt $clear, 'FE';
>      ok APR::Util::password_validate($clear, $hash);
>
>      Apache::OK;
>
>Does this make any difference?
>
No, although the hardcoded hash is different to what crypt() returns in 
my Perl:

C:\Temp\modperl-2.0>perl -e "print crypt 'pass1', 'FE'"
FExG070GemhK6

>
>Also how does modperl/exit fail?
>
Reported in a new thread.

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]

> OK, I found it:  It's the section commented "### $p->clear ###".  In 
> fact, if I reduce the handler in t/response/TestAPR/pool.pm to just this:
> 
> sub handler {
>     my $r = shift;
> 
>     plan $r, tests => 7;
> 
>     ### $p->clear ###
>     {
>         my ($pp, $sp) = both_pools_create_ok($r);
>         $pp->clear;
>         both_pools_destroy_ok($r);
>         $pp->destroy;
>     }
> 
>     Apache::OK;
> }
> 
> then it still causes compat/send_fd.t to fail.
> 
> But if I then comment-out the line "$pp->destroy", then compat/send_fd.t 
> now succeeds.

Great, Thanks Steve. As this is a not very important method at the moment and 
since I can't reproduce the problem myself, I have just commented it out for 
now and logged the issue. Will come back to it some time later, unless someone 
else looks into it and resolves it.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>Steve Hay wrote:
>  
>
>>Stas Bekman wrote:
>>
>>
>>    
>>
>>>Steve Hay wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>As I reported recently, compat/send_fd.t and directive/setupenv.t both 
>>>>currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32, 
>>>>but work when tried in isolation.
>>>>
>>>>After a little trial & error, I've found that running apr/pool.t before 
>>>>them make them fail, i.e.
>>>>
>>>>  perl t/TEST compat/send_fd
>>>>  perl t/TEST directive/setupenv
>>>>  
>>>>
>>>>        
>>>>
>>>Actually, please just try the current cvs. I've committed some adjustments for 
>>>the apr test
>>>
>>>      
>>>
>>Just grabbed the current cvs; it makes no difference to the above 
>>results, 
>>    
>>
>
>Could you try the the binary search technique, trying to cut off sub-tests 
>until you get one to blame?
>
OK, I found it:  It's the section commented "### $p->clear ###".  In 
fact, if I reduce the handler in t/response/TestAPR/pool.pm to just this:

sub handler {
    my $r = shift;

    plan $r, tests => 7;

    ### $p->clear ###
    {
        my ($pp, $sp) = both_pools_create_ok($r);
        $pp->clear;
        both_pools_destroy_ok($r);
        $pp->destroy;
    }

    Apache::OK;
}

then it still causes compat/send_fd.t to fail.

But if I then comment-out the line "$pp->destroy", then compat/send_fd.t 
now succeeds.

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
> 
> 
>>Steve Hay wrote:
>> 
>>
>>
>>>As I reported recently, compat/send_fd.t and directive/setupenv.t both 
>>>currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32, 
>>>but work when tried in isolation.
>>>
>>>After a little trial & error, I've found that running apr/pool.t before 
>>>them make them fail, i.e.
>>>
>>>   perl t/TEST compat/send_fd
>>>   perl t/TEST directive/setupenv
>>>   
>>>
>>
>>Actually, please just try the current cvs. I've committed some adjustments for 
>>the apr test
>>
> 
> Just grabbed the current cvs; it makes no difference to the above 
> results, 

Could you try the the binary search technique, trying to cut off sub-tests 
until you get one to blame? In such cases I use Apache::Reload:

PerlModule Apache::Reload
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
PerlSetVar ReloadModules "TestAPR::*"

# adjust above the pattern

and then I start the server:

t/TEST -start

and then modify and run the tests with:

t/TEST -run -v ...

so the process is much faster, no need to wait for the server startup.

> and I now have two other tests (apr/util and modperl/exit) 
> failing too (on their own, that is, not just after apr/pool).

What do you mean 'now', there weren't failing yesterday and started to fail now?

The common things for some of these tests is that they use methods that throw 
exceptions. But it could be something else.

apr/util is not one of them, and it uses a very simple XS wrapper. Though this 
is what I've added recently:

     my $clear = "pass1";
     my $hash  = "1fWDc9QWYCWrQ";
     ok APR::Util::password_validate($clear, $hash);

it's quite possible that this doesn't work on windows. It really does crypt. 
Try replacing hardcoded hash of the password with crypt:


Index: t/response/TestAPR/util.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/util.pm,v
retrieving revision 1.8
diff -u -r1.8 util.pm
--- t/response/TestAPR/util.pm  22 May 2004 21:47:32 -0000      1.8
+++ t/response/TestAPR/util.pm  25 May 2004 08:16:52 -0000
@@ -23,7 +23,7 @@
      ok ! APR::Util::password_validate("one", "two");

      my $clear = "pass1";
-    my $hash  = "1fWDc9QWYCWrQ";
+    my $hash  = crypt $clear, 'FE';
      ok APR::Util::password_validate($clear, $hash);

      Apache::OK;

Does this make any difference?

Also how does modperl/exit fail?

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32

Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:

>Steve Hay wrote:
>  
>
>>As I reported recently, compat/send_fd.t and directive/setupenv.t both 
>>currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32, 
>>but work when tried in isolation.
>>
>>After a little trial & error, I've found that running apr/pool.t before 
>>them make them fail, i.e.
>>
>>    perl t/TEST compat/send_fd
>>    perl t/TEST directive/setupenv
>>    
>>
>
>Actually, please just try the current cvs. I've committed some adjustments for 
>the apr test
>
Just grabbed the current cvs; it makes no difference to the above 
results, and I now have two other tests (apr/util and modperl/exit) 
failing too (on their own, that is, not just after apr/pool).

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: apr/pool makes compat/send_fd & driective/setupenv fail on Win32

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> As I reported recently, compat/send_fd.t and directive/setupenv.t both 
> currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32, 
> but work when tried in isolation.
> 
> After a little trial & error, I've found that running apr/pool.t before 
> them make them fail, i.e.
> 
>     perl t/TEST compat/send_fd
>     perl t/TEST directive/setupenv

Actually, please just try the current cvs. I've committed some adjustments for 
the apr test

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org