On Wed, 25 Sep 2019 at 03:59, Adam Prime <adam.pr...@utoronto.ca> wrote:
> Still seeing the t/api/request_rec.t failures, which do not occur with
> the same machine and same settings with 2.0.10. It's failing after the
> mtime test, before the finfo test.
> Test Summary Report
> -------------------
> t/api/request_rec.t                   (Wstat: 0 Tests: 43 Failed: 0)
>    Parse errors: Bad plan.  You planned 55 tests but ran 43.
> t/filter/in_bbs_inject_header.t       (Wstat: 0 Tests: 36 Failed: 3)
>    Failed tests:  22, 26, 30
> Files=245, Tests=3402, 98 wallclock secs ( 0.71 usr  0.30 sys + 67.05
> cusr 12.05 csys = 80.11 CPU)
> Result: FAIL
> Failed 2/245 test programs. 3/3402 subtests failed.
> This is what i see in the error_log:
> [Tue Sep 24 22:56:10.012601 2019] [perl:error] [pid 743] [client
>] APR::Finfo::stat: (70008) Partial results are valid but
> processing is incomplete at
> /tmp/mod_perl-2.0.11-rc2/t/response/TestAPI/request_rec.pm line 168
> Not sure if this is a concern or not, but it seems like it should be?

Yes, it's definitely a concern! We have two reports of exactly the
same failure now - this and the one from Damyan Ivanov.

This is exactly the kind of problem that I was getting with libapr's
apr_stat() function (see
https://bz.apache.org/bugzilla/show_bug.cgi?id=51560), which I fixed
for Windows in rev. 1865449. As noted before I do see various test
failures on Windows, but none relating to apr_stat() now, and I don't
get any api/request_rec.t failure at all.

This seems to imply either that other OSes are getting similar
problems that need working around similarly to Windows, or else that
the Windows fixes I've applied have broken other OSes. In this case
I'm wondering if it might the latter:-

The rev. cited above changed exactly the line that the failure is
reported on - line 168 in t/response/TestAPI/request_rec.pm... I
changed FINFO_NORM to FINFO_NAME since it's only fname that we access
so we shouldn't need all the other fields. (Windows has a problem
getting all the fields (specifically, it often fails on the
APR_FINFO_GPROT and APR_FINFO_WPROT bits) so that change dodged the
problem for me.)

What happens if you revert the change in that file? I.e. Change
FINFO_NAME back to FINFO_NORM on line 168, and on line 18 (the
APR::Const -compile line)? Does that fix it for you?

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

Reply via email to