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 > 127.0.0.1:57720] 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
