test failure w Apache 2.4, perl-5.24.0 and trunk
Since Steve Hay asked for trunk vs 5.24 and 2.4 reports, I gave it a whirl on Omnios/Illumos. t/filter/in_bbs_inject_header.t is my only fail with useithreads=undef perl and -with-mpm=prefork httpd. John groenv...@acm.org $ env PATH=/opt/apache24/bin:/opt/apache24/perl-5.24.0/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/gcc-5.1.0/bin:/usr/gnu/bin:/usr/sfw/bin perl Makefile.PL APXS=/opt/apache24/bin/apxs MAKE=gmake MP_NO_THREADS=1 [warning] Skipping 'set unlimited ulimit for coredumps', since we are running as a non-root user on Solaris /opt/apache24/bin/httpd -d /home/bernice.1/john/trunk/t -f /home/bernice.1/john/trunk/t/conf/httpd.conf -D APACHE2 -D APACHE2_4 using Apache/2.4.23 (prefork MPM) waiting 300 seconds for server to start: .[Fri Jul 22 17:37:41.545978 2016] [env:warn] [pid 26677] AH01506: PassEnv variable LD_LIBRARY_PATH was undefined [Fri Jul 22 17:37:41.603542 2016] [perl:info] [pid 26677] 6 Apache2:: modules loaded [Fri Jul 22 17:37:41.603624 2016] [perl:info] [pid 26677] 0 APR:: modules loaded [Fri Jul 22 17:37:41.603700 2016] [perl:info] [pid 26677] base server + 32 vhosts ready to run tests ... waiting 300 seconds for server to start: ok (waited 3 secs) server localhost:8529 started server localhost:8530 listening (perlsections) server localhost:8531 listening (inherit) server localhost:8532 listening (filter_out_apache) server localhost:8533 listening (TestUser::rewrite) server localhost:8534 listening (TestModperl::merge) server localhost:8535 listening (TestModperl::setupenv) server localhost:8536 listening (TestModperl::perl_options2) server localhost:8537 listening (TestModperl::perl_options) server localhost:8538 listening (TestVhost::config) server localhost:8539 listening (TestVhost::log) server localhost:8540 listening (TestDirective::perlcleanuphandler) server localhost:8541 listening (TestModules::proxy) server localhost:8542 listening (TestProtocol::pseudo_http) server localhost:8543 listening (TestProtocol::echo_filter) server localhost:8544 listening (TestProtocol::eliza) server localhost:8545 listening (TestProtocol::echo_nonblock) server localhost:8546 listening (TestProtocol::echo_timeout) server localhost:8547 listening (TestProtocol::echo_bbs2) server localhost:8548 listening (TestProtocol::echo_block) server localhost:8549 listening (TestProtocol::echo_bbs) server localhost:8550 listening (TestPreConnection::note) server localhost:8551 listening (TestHooks::stacked_handlers2) server localhost:8552 listening (TestHooks::startup) server localhost:8553 listening (TestHooks::init) server localhost:8554 listening (TestHooks::hookrun) server localhost:8555 listening (TestHooks::trans) server localhost:8556 listening (TestFilter::in_bbs_inject_header) server localhost:8557 listening (TestFilter::in_str_msg) server localhost:8558 listening (TestFilter::in_bbs_msg) server localhost:8559 listening (TestFilter::both_str_con_add) server localhost:8560 listening (TestDirective::perlrequire) server localhost:8561 listening (TestDirective::perlmodule) server localhost:8562 listening (TestPerl::ithreads) server localhost:8563 listening (TestPerl::ithreads3) server localhost:8564 listening (TestDirective::perlloadmodule3) server localhost:8565 listening (TestDirective::perlloadmodule5) server localhost:8566 listening (TestDirective::perlloadmodule4) server localhost:8567 listening (TestAPI::add_config) server localhost:8568 listening (TestDirective::perlloadmodule6) server localhost:8569 listening (TestHooks::push_handlers_anon) # Failed test 22 in t/filter/in_bbs_inject_header.t at line 58 fail #6 # Failed test 26 in t/filter/in_bbs_inject_header.t at line 58 fail #7 # Failed test 30 in t/filter/in_bbs_inject_header.t at line 58 fail #8 t/filter/in_bbs_inject_header.t .. # connecting to localhost:8556 1..36 # Running under perl version 5.024000 for solaris # Current time local: Fri Jul 22 17:37:46 2016 # Current time GMT: Fri Jul 22 21:37:46 2016 # Using Test.pm version 1.28 # Using Apache/Test.pm version 1.39 # testing : body # expected: 'This body shouldn\'t be seen by the filter' # received: 'This body shouldn\'t be seen by the filter' ok 1 # testing : injected header X-My-Protocol # expected: 'POST-IT' # received: 'POST-IT' ok 2 # testing : injected header X-Extra-Header2 # expected: 'Value 2' # received: 'Value 2' ok 3 # testing : injected header X-Extra-Header3 # expected: 'Value 3' # received: 'Value 3' ok 4 # testing : body # expected: 'This body shouldn\'t be seen by the filter' # received: 'This body shouldn\'t be seen by the filter' ok 5 # testing : injected header X-My-Protocol # expected: 'POST-IT' # received: 'POST-IT' ok 6 # testing : injected header X-Extra-Header2 # expected: 'Value 2' # received: 'Value 2' ok 7 # testing : injected header X-Extra-Header3 # expected: 'Value 3' # received: 'Value 3' ok 8 # testing : body # expected: 'This body shouldn\'t be seen by the filter' # received: 'This body shouldn\'t be seen by the filter' ok 9 # testing : inject
Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)
Thanks for the heads up ... will definitely put that on the roadmap. For now I will stick to 2.2 to reduce the number of things that might go wrong, but once we get stable on this version I'll look into 2.4 Bill On 7/22/2016 12:27 PM, John D Groenveld wrote: In message , William A Rowe Jr writes: Note that httpd 2.4.23 announcement warned of the imminent end of httpd 2.2 as well. You would do well to build your httpd 2.4 / perl 5.24 / mod perl.next that should be tagged soon as your next stack. http://mail-archives.apache.org/mod_mbox/httpd-announce/201607.mbox/browser> | Please note that Apache Web Server Project will only provide maintenance | releases of the 2.2.x flavor through June of 2017, and will provide some | security patches beyond this date through at least December of 2017. | Minimal maintenance patches of 2.2.x are expected throughout this period, | and users are strongly encouraged to promptly complete their transitions | to the the 2.4.x flavor of httpd to benefit from a much larger assortment | of minor security and bug fixes as well as new features. John groenv...@acm.org
Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)
In message , William A Rowe Jr writes: >Note that httpd 2.4.23 announcement warned of the imminent end of httpd 2.2 >as well. You would do well to build your httpd 2.4 / perl 5.24 / mod >perl.next that should be tagged soon as your next stack. http://mail-archives.apache.org/mod_mbox/httpd-announce/201607.mbox/browser> | Please note that Apache Web Server Project will only provide maintenance | releases of the 2.2.x flavor through June of 2017, and will provide some | security patches beyond this date through at least December of 2017. | Minimal maintenance patches of 2.2.x are expected throughout this period, | and users are strongly encouraged to promptly complete their transitions | to the the 2.4.x flavor of httpd to benefit from a much larger assortment | of minor security and bug fixes as well as new features. John groenv...@acm.org
Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)
On Jul 21, 2016 8:24 PM, "William Ward" wrote: > > OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS status by the Perl gods. Hopefully a new mod_perl will come out that includes this fix. Note that httpd 2.4.23 announcement warned of the imminent end of httpd 2.2 as well. You would do well to build your httpd 2.4 / perl 5.24 / mod perl.next that should be tagged soon as your next stack.
Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)
Sorry, with all the things we're upgrading I don't want to add the variable of experimental code into the mix. I'll just run 5.20.3 for now. Bill On 7/22/2016 12:12 AM, Steve Hay wrote: Yes, I intend to make a new mod_perl release with the fix very soon after two maint perl releases (5.22.3 / 5.24.1) are done. Sorry this fix has languished so long. In the meantime, if you're able to grab the latest SVN source and try it then that would be a great help: It should be good to go, but more testing is mostly what it needs. On 22 July 2016 at 02:24, William Ward wrote: OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS status by the Perl gods. Hopefully a new mod_perl will come out that includes this fix. Bill. On 7/21/2016 6:10 PM, Adam Prime wrote: there are changes in SVN to support perls >= 5.22, but the work hasn't been released and may not be complete yet. This is the bug: https://rt.cpan.org/Public/Bug/Display.html?id=101962 If you can downgrade your perl to 5.20 then you should be able to get things running. Adam On 07/21/2016 05:16 PM, William Ward wrote: -8<-- Start Bug Report 8<-- 1. Problem Description: Until recently we have been using Perl 5.8.8, Apache 2.2.29, and mod_perl 2.0.8. Due to migration to a new platform, it is necessary to rebuild our tech stack, so I am taking this opportunity to upgrade (Perl 5.8.8 doesn't want to build on the new platform anyway). Everything compiles fine, and Apache and Perl have no issues but mod_perl has failures running "make test": Test Summary Report --- t/api/uri.t (Wstat: 0 Tests: 12 Failed: 0) Parse errors: Bad plan. You planned 24 tests but ran 12. t/apr-ext/uri.t (Wstat: 65280 Tests: 12 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 36 tests but ran 12. t/apr/uri.t (Wstat: 0 Tests: 12 Failed: 0) Parse errors: Bad plan. You planned 36 tests but ran 12. t/directive/perlloadmodule3.t (Wstat: 0 Tests: 3 Failed: 3) Failed tests: 1-3 t/filter/both_str_native_remove.t (Wstat: 0 Tests: 8 Failed: 4) Failed tests: 1, 6-8 t/modperl/print.t (Wstat: 0 Tests: 5 Failed: 0) Parse errors: Bad plan. You planned 6 tests but ran 5. t/modperl/printf.t(Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output Files=245, Tests=2223, 136 wallclock secs ( 1.16 usr 2.63 sys + 80.27 cusr 35.91 csys = 119.97 CPU) Result: FAIL Failed 7/245 test programs. 7/2223 subtests failed. I re-ran the tests mentioned above using -verbose mode, and the results are below. % t/TEST -verbose api/uri apr-ext/uri apr/uri directive/perlloadmodule3 filter/both_str_native_remove modperl/print modperl/printf [warning] setting ulimit to allow core files ulimit -c unlimited; /arudev/tech-stack/16.09.16.06/linux/bin/perl /scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/TEST -verbose 'api/uri' 'apr-ext/uri' 'apr/uri' 'directive/perlloadmodule3' 'filter/both_str_native_remove' 'modperl/print' 'modperl/printf' /arudev/tech-stack/16.09.16.06/linux/bin/httpd -d /scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t -f /scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/conf/httpd.conf -D APACHE2 using Apache/2.2.31 (prefork MPM) waiting 120 seconds for server to start: .[Thu Jul 21 14:01:34 2016] [info] 6 Apache2:: modules loaded [Thu Jul 21 14:01:34 2016] [info] 0 APR:: modules loaded [Thu Jul 21 14:01:34 2016] [info] base server + 29 vhosts ready to run tests .. waiting 120 seconds for server to start: ok (waited 2 secs) server localhost.localdomain:8529 started server localhost.localdomain:8530 listening (perlsections) server localhost.localdomain:8531 listening (inherit) server localhost.localdomain:8532 listening (filter_out_apache) server localhost.localdomain:8533 listening (TestVhost::log) server localhost.localdomain:8534 listening (TestVhost::config) server localhost.localdomain:8535 listening (TestModperl::setupenv) server localhost.localdomain:8536 listening (TestModperl::perl_options2) server localhost.localdomain:8537 listening (TestModperl::perl_options) server localhost.localdomain:8538 listening (TestModperl::merge) server localhost.localdomain:8539 listening (TestDirective::perlcleanuphandler) server localhost.localdomain:8540 listening (TestModules::proxy) server localhost.localdomain:8541 listening (TestUser::rewrite) server localhost.localdomain:8542 listening (TestProtocol::echo_bbs) server localhost.localdomain:8543 listening (TestProtocol::echo_timeout) server localhost.localdomain:8544 listening (TestProtocol::echo_block) server localhost.localdomain:8545 listening (TestProtocol::pseudo_http) server localhost.localdomain:8546 listening (TestProtocol:
Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)
I thought I saw somewhere the term LTS used with respect to Perl 5.24 but can't find it now... however they do push pretty hard to run the latest version: * On https://www.perl.org/get.html it says, "We recommend that you always run the latest stable version, currently 5.24.0. If you're running a version older than 5.8.3, you may find that the latest version of CPAN modules will not work." * On http://www.cpan.org/src/README.html it says "End of life" for all versions earlier than 5.22.2 If mod_perl doesn't work on any version except those marked "End of life" in CPAN, I think that's a problem. Bill On 7/22/2016 1:47 AM, Dominic Hargreaves wrote: On Thu, Jul 21, 2016 at 06:24:05PM -0700, William Ward wrote: OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS status by the Perl gods. Hopefully a new mod_perl will come out that includes this fix. Where do you find a reference to LTS support for perl 5.24.0? As far as I know the support policy is unchanged and uniform for each stable release: http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-AND-SUPPORT Cheers, Dominic.
Re: write handlers with C or modperl?
I think it really depends on what the handler is doing. If it is mainly executing some db queries rewriting it in C won't make much of a difference. If the handler is doing some expensive computation it might be worth it. Before you rewrite the whole handler though you should look at the option of just implementing the expensive parts and using XS-bindings to load them into the perl handler. That is actually what we did: implementing expensive parser logic that rarely changes in C and calling it from perl while leaving the often-changing business logic in perl. We also catch the most frequently used calls in the nginx reverse proxy and use lua there to fast-track them. In the end it is always a trade-off between performance and maintainability so optimizations like that should only be done on a very limited scope. Hendrik Am 22.07.2016 um 11:53 schrieb André Warnier (tomcat): On 22.07.2016 11:00, yhp...@orange.fr wrote: Hello, We have some handlers which were written by modperl for API endpoints. yes developing a apache handler with modperl is so easy and quick. but for better performance we also consider the C handler. (one of the APIs has got 1,500,000 accesses by unique clients) Do you think if it's valuable to change the handler from modperl to pure C? for C coding we have to take more time to develop, debug and maintain. You have asked the question, and partially answered it yourself. (Just ad the fact that to use mod_perl, means having a perl interpreter in each of your Apache httpd children processes, which is a significant memory overhead). Ask yourself also if you need perl in Apache for anything else than these "some" handlers. If you do, then you have to keep perl anyway, and you would not gain anything (in terms of memory) by moving your handlers to C. As to the overall question, nobody can answer this but yourself. My company runs a bunch (dozens, not hundreds) of websites for customers, under Apache/mod_perl, since many years. The applications are customised and quite sophisticated, but the individual traffic on each website is moderate (not millions per day like you). Over these many years, we have found mod_perl *invaluable* in terms of the flexibility and rapid development that it provides to us, to accomodate a wide range of ever-changing customer requirements in terms of data-entry, user authentication, input and output filtering, etc. etc. (and not least, the availability of CPAN modules, to achieve almost anything you can dream of). So we would not even dream of doing without mod_perl or something at least equivalent; and there /is/ nothing else really equivalent under Apache httpd, when it comes to interacting more deeply with the HTTP request/response cycle than just running some CGI scripts. But if your applications are different (more standard and stable over time e.g.), then maybe you can squeeze some additional performance by converting all or some of your handlers to C. But again, you have to decide that for yourself. I believe that it is maybe the "drama" of mod_perl : it is so powerful, and so flexible, that you kind of get used to it and blasé. Using it, nothing to do with HTTP seems impossible anymore, and nothing requires very large resources or a lot of time to do. Consequently, a development team using mod_perl does not need to get very large, to achieve quite complex things and keep them running. And consequently, such teams tend to remain small and have small budgets, which does not give them (or mod_perl) a very high profile. To get back to your question, maybe there is an intellectual experiment that you can do : Imagine that tomorrow, you get a new management directive, saying that within 6 months all usage of perl and mod_perl on your websites needs to be stopped. And try to figure out what this would cost, in terms of finding alternatives, implementing them and maintaining them over time.
Re: write handlers with C or modperl?
yes I totally agree with you, modperl is also perl, it has the big advantage of using CPAN. for example, we have used these modules in the project, Data::Validate::Domain Data::Validate::Email Data::Validate::IP I don't think they are easy to port into C language. So perl is great, modperl is powerful. regards. On 2016/7/22 17:53, André Warnier (tomcat) wrote: On 22.07.2016 11:00, yhp...@orange.fr wrote: Hello, We have some handlers which were written by modperl for API endpoints. yes developing a apache handler with modperl is so easy and quick. but for better performance we also consider the C handler. (one of the APIs has got 1,500,000 accesses by unique clients) Do you think if it's valuable to change the handler from modperl to pure C? for C coding we have to take more time to develop, debug and maintain. You have asked the question, and partially answered it yourself. (Just ad the fact that to use mod_perl, means having a perl interpreter in each of your Apache httpd children processes, which is a significant memory overhead). Ask yourself also if you need perl in Apache for anything else than these "some" handlers. If you do, then you have to keep perl anyway, and you would not gain anything (in terms of memory) by moving your handlers to C. As to the overall question, nobody can answer this but yourself. My company runs a bunch (dozens, not hundreds) of websites for customers, under Apache/mod_perl, since many years. The applications are customised and quite sophisticated, but the individual traffic on each website is moderate (not millions per day like you). Over these many years, we have found mod_perl *invaluable* in terms of the flexibility and rapid development that it provides to us, to accomodate a wide range of ever-changing customer requirements in terms of data-entry, user authentication, input and output filtering, etc. etc. (and not least, the availability of CPAN modules, to achieve almost anything you can dream of). So we would not even dream of doing without mod_perl or something at least equivalent; and there /is/ nothing else really equivalent under Apache httpd, when it comes to interacting more deeply with the HTTP request/response cycle than just running some CGI scripts. But if your applications are different (more standard and stable over time e.g.), then maybe you can squeeze some additional performance by converting all or some of your handlers to C. But again, you have to decide that for yourself. I believe that it is maybe the "drama" of mod_perl : it is so powerful, and so flexible, that you kind of get used to it and blasé. Using it, nothing to do with HTTP seems impossible anymore, and nothing requires very large resources or a lot of time to do. Consequently, a development team using mod_perl does not need to get very large, to achieve quite complex things and keep them running. And consequently, such teams tend to remain small and have small budgets, which does not give them (or mod_perl) a very high profile. To get back to your question, maybe there is an intellectual experiment that you can do : Imagine that tomorrow, you get a new management directive, saying that within 6 months all usage of perl and mod_perl on your websites needs to be stopped. And try to figure out what this would cost, in terms of finding alternatives, implementing them and maintaining them over time.
Re: write handlers with C or modperl?
On 22.07.2016 11:00, yhp...@orange.fr wrote: Hello, We have some handlers which were written by modperl for API endpoints. yes developing a apache handler with modperl is so easy and quick. but for better performance we also consider the C handler. (one of the APIs has got 1,500,000 accesses by unique clients) Do you think if it's valuable to change the handler from modperl to pure C? for C coding we have to take more time to develop, debug and maintain. You have asked the question, and partially answered it yourself. (Just ad the fact that to use mod_perl, means having a perl interpreter in each of your Apache httpd children processes, which is a significant memory overhead). Ask yourself also if you need perl in Apache for anything else than these "some" handlers. If you do, then you have to keep perl anyway, and you would not gain anything (in terms of memory) by moving your handlers to C. As to the overall question, nobody can answer this but yourself. My company runs a bunch (dozens, not hundreds) of websites for customers, under Apache/mod_perl, since many years. The applications are customised and quite sophisticated, but the individual traffic on each website is moderate (not millions per day like you). Over these many years, we have found mod_perl *invaluable* in terms of the flexibility and rapid development that it provides to us, to accomodate a wide range of ever-changing customer requirements in terms of data-entry, user authentication, input and output filtering, etc. etc. (and not least, the availability of CPAN modules, to achieve almost anything you can dream of). So we would not even dream of doing without mod_perl or something at least equivalent; and there /is/ nothing else really equivalent under Apache httpd, when it comes to interacting more deeply with the HTTP request/response cycle than just running some CGI scripts. But if your applications are different (more standard and stable over time e.g.), then maybe you can squeeze some additional performance by converting all or some of your handlers to C. But again, you have to decide that for yourself. I believe that it is maybe the "drama" of mod_perl : it is so powerful, and so flexible, that you kind of get used to it and blasé. Using it, nothing to do with HTTP seems impossible anymore, and nothing requires very large resources or a lot of time to do. Consequently, a development team using mod_perl does not need to get very large, to achieve quite complex things and keep them running. And consequently, such teams tend to remain small and have small budgets, which does not give them (or mod_perl) a very high profile. To get back to your question, maybe there is an intellectual experiment that you can do : Imagine that tomorrow, you get a new management directive, saying that within 6 months all usage of perl and mod_perl on your websites needs to be stopped. And try to figure out what this would cost, in terms of finding alternatives, implementing them and maintaining them over time.
write handlers with C or modperl?
Hello, We have some handlers which were written by modperl for API endpoints. yes developing a apache handler with modperl is so easy and quick. but for better performance we also consider the C handler. (one of the APIs has got 1,500,000 accesses by unique clients) Do you think if it's valuable to change the handler from modperl to pure C? for C coding we have to take more time to develop, debug and maintain. Thanks.
Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)
On Thu, Jul 21, 2016 at 06:24:05PM -0700, William Ward wrote: > OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS > status by the Perl gods. Hopefully a new mod_perl will come out that > includes this fix. Where do you find a reference to LTS support for perl 5.24.0? As far as I know the support policy is unchanged and uniform for each stable release: http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-AND-SUPPORT Cheers, Dominic.
Re: [mp2] Test failures in mod_perl 2.0.9 (Apache 2.2.31, perl 5.24.0)
Yes, I intend to make a new mod_perl release with the fix very soon after two maint perl releases (5.22.3 / 5.24.1) are done. Sorry this fix has languished so long. In the meantime, if you're able to grab the latest SVN source and try it then that would be a great help: It should be good to go, but more testing is mostly what it needs. On 22 July 2016 at 02:24, William Ward wrote: > OK I will give that a try. Unfortunate, as 5.24.0 has been blessed with LTS > status by the Perl gods. Hopefully a new mod_perl will come out that > includes this fix. > > Bill. > > > > On 7/21/2016 6:10 PM, Adam Prime wrote: >> >> there are changes in SVN to support perls >= 5.22, but the work hasn't >> been released and may not be complete yet. This is the bug: >> >> https://rt.cpan.org/Public/Bug/Display.html?id=101962 >> >> If you can downgrade your perl to 5.20 then you should be able to get >> things running. >> >> Adam >> >> >> On 07/21/2016 05:16 PM, William Ward wrote: >>> >>> -8<-- Start Bug Report 8<-- >>> 1. Problem Description: >>> >>> Until recently we have been using Perl 5.8.8, Apache 2.2.29, and >>> mod_perl 2.0.8. Due to migration to a new platform, it is necessary to >>> rebuild our tech stack, so I am taking this opportunity to upgrade >>> (Perl 5.8.8 doesn't want to build on the new platform anyway). >>> >>> Everything compiles fine, and Apache and Perl have no issues but >>> mod_perl has failures running "make test": >>> >>> Test Summary Report >>> --- >>> t/api/uri.t (Wstat: 0 Tests: 12 Failed: 0) >>>Parse errors: Bad plan. You planned 24 tests but ran 12. >>> t/apr-ext/uri.t (Wstat: 65280 Tests: 12 Failed: 0) >>>Non-zero exit status: 255 >>>Parse errors: Bad plan. You planned 36 tests but ran 12. >>> t/apr/uri.t (Wstat: 0 Tests: 12 Failed: 0) >>>Parse errors: Bad plan. You planned 36 tests but ran 12. >>> t/directive/perlloadmodule3.t (Wstat: 0 Tests: 3 Failed: 3) >>>Failed tests: 1-3 >>> t/filter/both_str_native_remove.t (Wstat: 0 Tests: 8 Failed: 4) >>>Failed tests: 1, 6-8 >>> t/modperl/print.t (Wstat: 0 Tests: 5 Failed: 0) >>>Parse errors: Bad plan. You planned 6 tests but ran 5. >>> t/modperl/printf.t(Wstat: 65280 Tests: 0 Failed: 0) >>>Non-zero exit status: 255 >>>Parse errors: No plan found in TAP output >>> Files=245, Tests=2223, 136 wallclock secs ( 1.16 usr 2.63 sys + 80.27 >>> cusr 35.91 csys = 119.97 CPU) >>> Result: FAIL >>> Failed 7/245 test programs. 7/2223 subtests failed. >>> >>> I re-ran the tests mentioned above using -verbose mode, and the >>> results are below. >>> >>> % t/TEST -verbose api/uri apr-ext/uri apr/uri >>> directive/perlloadmodule3 filter/both_str_native_remove modperl/print >>> modperl/printf >>> [warning] setting ulimit to allow core files >>> ulimit -c unlimited; /arudev/tech-stack/16.09.16.06/linux/bin/perl >>> >>> /scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/TEST >>> -verbose 'api/uri' 'apr-ext/uri' 'apr/uri' 'directive/perlloadmodule3' >>> 'filter/both_str_native_remove' 'modperl/print' 'modperl/printf' >>> /arudev/tech-stack/16.09.16.06/linux/bin/httpd -d >>> >>> /scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t >>> -f >>> >>> /scratch/wward/build/tech-stack/build/16.09.16.06/linux/cpan/build/mod_perl-2.0.9/t/conf/httpd.conf >>> -D APACHE2 >>> using Apache/2.2.31 (prefork MPM) >>> >>> waiting 120 seconds for server to start: .[Thu Jul 21 14:01:34 2016] >>> [info] 6 Apache2:: modules loaded >>> [Thu Jul 21 14:01:34 2016] [info] 0 APR:: modules loaded >>> [Thu Jul 21 14:01:34 2016] [info] base server + 29 vhosts ready to run >>> tests >>> .. >>> waiting 120 seconds for server to start: ok (waited 2 secs) >>> server localhost.localdomain:8529 started >>> server localhost.localdomain:8530 listening (perlsections) >>> server localhost.localdomain:8531 listening (inherit) >>> server localhost.localdomain:8532 listening (filter_out_apache) >>> server localhost.localdomain:8533 listening (TestVhost::log) >>> server localhost.localdomain:8534 listening (TestVhost::config) >>> server localhost.localdomain:8535 listening (TestModperl::setupenv) >>> server localhost.localdomain:8536 listening (TestModperl::perl_options2) >>> server localhost.localdomain:8537 listening (TestModperl::perl_options) >>> server localhost.localdomain:8538 listening (TestModperl::merge) >>> server localhost.localdomain:8539 listening >>> (TestDirective::perlcleanuphandler) >>> server localhost.localdomain:8540 listening (TestModules::proxy) >>> server localhost.localdomain:8541 listening (TestUser::rewrite) >>> server localhost.localdomain:8542 listening (TestProtocol::echo_bbs) >>> server localhost.localdomain:8543 listening (TestProtocol::echo_timeout) >>> server localhost.localdomain:8544 listening (T
