Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On 01/15/2013 09:07 PM, Dennis Clarke wrote: Number of tests : 12276 8329 Tests skipped : 3947 ( 32.2%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:2 ( 0.0%) ( 0.0%) Expected fail : 36 ( 0.3%) ( 0.4%) Tests passed: 8291 ( 67.5%) ( 99.5%) Right, so 8291 tests passed and 2 failed. That's pretty close to clean on RHEL 6. The expected fails are ones we know are failing and are work-in-progress things. In that case .. perfect. Now then .. I will go back to looking at the build on Solaris and see if I can begine to isolate failures. dc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
/** For the sake of getting this issue looked into I am going to cross post * to two maillists. Maybe the PHP folks see the issue and will reply with an * update. Who knows. */ Original message to the bison mailist : Le 15 janv. 2013 à 00:19, Dennis Clarke dcla...@blastwave.org a écrit : Dear bison folks : Hi! This is not really a bug but rather a question. I recently saw that PHP had been updated to 5.4.10 and I decided to try building it. I was quite surprised to see in the configure output this warning about bison : checking for bison... bison -y checking for bison version... invalid configure: WARNING: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.6 2.6.1 2.6.2 (found: 2.6.5). This seems odd to me as bison 2.6.5 builds and tests perfectly on my Solaris 10 server and so therefore I wonder what these PHP folks are on about? I will look for some sort of reasonable dev list for the php folks as it would be a good idea to get some input from them. Any reply from the bison team would be appreciated also. [ from Akim Demaille on bison maillist ] I have no idea why this is checked/displayed. Maintaining backward compatibility is certainly a nice feature, but supporting 1.28 for instance seems completely pointless. Actually, it also means that they use no recent feature, which is sad. On the other end of the spectrum, I have no idea why they want to check the version this way. I am not aware of bugs in 2.7 for instance, yet I know issues 2.7 solves over 2.6.5, which itself is superior to 2.6.2. Really, I'd be happy to know more about this. Well there are other issues also as I have yet to see PHP build cleanly on Solaris 10. Every build of PHP going back a number of revs always results in FAILED TEST SUMMARY at the end of the testsuite as well as You may have found a problem in PHP. My configure line looks like : ./configure --with-apxs2=/usr/local/bin/apxs --with-mysql=/opt/mysql/mysql \ --with-libxml-dir=/usr/local --sysconfdir=/usr/local/etc \ --includedir=/usr/local/include --libdir=/usr/local/lib \ --libexecdir=/usr/local/libexec --localstatedir=/usr/local/var/php \ --mandir=/usr/share/man --infodir=/usr/local/share \ --cache-file=../php-5.4.10_SunOS5.10_sparcv9.config.cache --disable-debug \ --with-pic --with-bz2 --with-gettext --with-gmp --with-iconv --with-openssl \ --with-zlib --enable-ftp --enable-sockets --without-kerberos \ --enable-calendar --enable-xml --disable-json --with-curl=/usr/local \ --enable-posix Where apache 2.4.3 is up and running and has been for a while now as well as a host of other GNU tools that will not get installed unless they pass their own testsuite flawlessly. To get that to happen I did need to contribute back to flex and a few others but the work is worth it. What then will it take to get PHP to compile from a release tarball ? Shall I create a clean Solaris zone sandbox first and test a build there with Oracle Solaris Studio 12.3 ? Really I would like to hear from the PHP folks on this as it seems as if PHP is quite fragile or perhaps simply mysterious. Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On 01/15/2013 05:03 PM, Dennis Clarke wrote: Really I would like to hear from the PHP folks on this as it seems as if PHP is quite fragile or perhaps simply mysterious. I don't think any of us test on Solaris regularly, so you can expect the odd test to fail, but in general it should build ok. And yes, we should update the bison check, or probably simply remove it at this point. There have been issues in the past, but as someone told you, the release tarball includes a generated parser so you can ignore the bison warning. If you are waiting for a completely warning-fee Solaris build, you will be waiting quite a while. It is simply not a high-priority platform for us. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On 01/15/2013 05:03 PM, Dennis Clarke wrote: Really I would like to hear from the PHP folks on this as it seems as if PHP is quite fragile or perhaps simply mysterious. I don't think any of us test on Solaris regularly, so you can expect the odd test to fail, but in general it should build ok. And yes, we should update the bison check, or probably simply remove it at this point. There have been issues in the past, but as someone told you, the release tarball includes a generated parser so you can ignore the bison warning. If you are waiting for a completely warning-fee Solaris build, you will be waiting quite a while. It is simply not a high-priority platform for us. I agree that Oracle has done the Solaris market no favours and were the result of the death of OpenSolaris however, having said all that, Solaris is a SUSv3 compliant commercial UNIX and thus one would think that open source code written to comply with some, or perhaps all, of the typical code standards, would be portable and would just work. Those old Solaris servers are still out there churning away. As for the odd test failing, I see this : Build complete. Don't forget to run 'make test'. = PHP : /usr/local/build/php-5.4.10_SunOS5.10_sparcv9/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.4.10 ZEND_VERSION: 2.4.0 PHP_OS : SunOS - SunOS node002 5.10 Generic_147440-23 sun4v INI actual : /usr/local/build/php-5.4.10_SunOS5.10_sparcv9/tmp-php.ini More .INIs : CWD : /usr/local/build/php-5.4.10_SunOS5.10_sparcv9 Extra dirs : VALGRIND: Not used = TIME START 2013-01-15 20:06:44 = . . . FAILED TEST SUMMARY - function with many parameters [tests/func/010.phpt] Test operator : 64bit long tests [tests/lang/operators/bitwiseAnd_basiclong_64bit.phpt] Test ~N operator : 64bit long tests [tests/lang/operators/bitwiseNot_basiclong_64bit.phpt] Test | operator : 64bit long tests [tests/lang/operators/bitwiseOr_basiclong_64bit.phpt] Test operator : 64bit long tests [tests/lang/operators/bitwiseShiftLeft_basiclong_64bit.phpt] Test operator : 64bit long tests [tests/lang/operators/bitwiseShiftRight_basiclong_64bit.phpt] Test ^ operator : 64bit long tests [tests/lang/operators/bitwiseXor_basiclong_64bit.phpt] Test % operator : 64bit long tests [tests/lang/operators/modulus_basiclong_64bit.phpt] Bug #39018 (Error control operator '@' fails to suppress Uninitialized string offset) [Zend/tests/bug39018.phpt] Bug #60350 No string escape code for ESC (ascii 27), normally \e [Zend/tests/bug60350.phpt] testing integer overflow (64bit) [Zend/tests/int_overflow_64bit.phpt] Bug #27780 (strtotime(+1 xxx) returns a wrong date/time) [ext/date/tests/bug27780.phpt] Bug #32555 (strtotime(tomorrow) can return false) [ext/date/tests/bug32555.phpt] Bug #33532 (Different output for strftime() and date()) [ext/date/tests/bug33532.phpt] Bug #45866 (decimal values fed to DateTime-modify() causes long execution times) [ext/date/tests/bug45866.phpt] Test strftime() function : usage variation - Checking large positive and negative float values to timestamp. [ext/date/tests/strftime_variation23.phpt] Test split() function : usage variations - out-of-range values for limit [ext/ereg/tests/split_variation_004.phpt] Test spliti() function : usage variations - out-of-range values for limit [ext/ereg/tests/spliti_variation_004.phpt] Bug #52209 (INPUT_ENV returns NULL for set variables (CLI)) [ext/filter/tests/bug52209.phpt] Gettext basic test with en_US locale that should be on nearly every system [ext/gettext/tests/gettext_basic-enus.phpt] Gettext basic test [ext/gettext/tests/gettext_basic.phpt] Test if bindtextdomain() returns string id if no directory path is set(if directory path is 'null') [ext/gettext/tests/gettext_bindtextdomain-cwd.phpt] Test dcgettext() functionality [ext/gettext/tests/gettext_dcgettext.phpt] Test dgettext() functionality [ext/gettext/tests/gettext_dgettext.phpt] Test if dngettext() returns the correct translations (optionally plural). [ext/gettext/tests/gettext_dngettext-plural.phpt] Test ngettext() functionality [ext/gettext/tests/gettext_ngettext.phpt] Bug #37176 (iconv_strpos() fails to find a string) [ext/iconv/tests/bug37176.phpt] Bug #37773 (iconv_substr() gives Unknown error when string length = 1) [ext/iconv/tests/bug37773.phpt] Bug #48289 (iconv_mime_encode() quoted-printable scheme is broken) [ext/iconv/tests/bug48289.phpt] Bug #51250 (iconv_mime_decode() does not ignore malformed Q-encoded words) [ext/iconv/tests/bug51250.phpt] Bug #52211 (iconv() returns part of string on error) [ext/iconv/tests/bug52211.phpt] Bug #52941 (The 'iconv_mime_decode_headers' function is skipping headers)
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On 01/15/2013 05:19 PM, Dennis Clarke wrote: I agree that Oracle has done the Solaris market no favours and were the result of the death of OpenSolaris however, having said all that, Solaris is a SUSv3 compliant commercial UNIX and thus one would think that open source code written to comply with some, or perhaps all, of the typical code standards, would be portable and would just work. Those old Solaris servers are still out there churning away. Sure, but there are very few of you and we have limited resources. We focus those resources on the platforms used by 95% of our users. Feel free to dig in and send us some patches. Needless to say, all of those tests pass on Linux, FreeBSD and likely OSX as well. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
Those old Solaris servers are still out there churning away. Sure, but there are very few of you and we have limited resources. granted ... I get it. I do. I ran Blastwave for a decade on shoestring and prayer and kicked out several thousand SVR4 packages. I really do get it. We focus those resources on the platforms used by 95% of our users. Feel free to dig in and send us some patches. Needless to say, all of those tests pass on Linux, FreeBSD and likely OSX as well. I will try that theory out on RHEL 6.3 and let you know. dc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
We focus those resources on the platforms used by 95% of our users. Feel free to dig in and send us some patches. Needless to say, all of those tests pass on Linux, FreeBSD and likely OSX as well. I will try that theory out on RHEL 6.3 and let you know. PHP is hardly what I would call fragile. Our QA process is rather intensive I think. In addition to the operating systems Rasmus mentioned, a lot of work goes into making sure they pass on Windows as well. I know it seems daunting, but if you want to maximize the chances that these issues will be addressed, I'd suggest you examine each test result in that list and post a bug report for it on bugs.php.net. I don't know how many people here are actually familiar with Solaris (I'm not), so that may mean that you're in a unique position to help us debug and troubleshoot these issues you've encountered. I wouldn't expect any immediate results, but getting them into the bug tracker would be an important first step if you don't want to submit all the patches yourself. =) --Kris
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On Tue, 2013-01-15 at 17:19 -0500, Dennis Clarke wrote: I agree that Oracle has done the Solaris market no favours and were the result of the death of OpenSolaris however, having said all that, Solaris is a SUSv3 compliant commercial UNIX and thus one would think that open source code written to comply with some, or perhaps all, of the typical code standards, would be portable and would just work. Those old Solaris servers are still out there churning away. As for the odd test failing, I see this : As I use Solaris on one of my primary machines I went through some of those tests in the past. The basic issue here is that no standard defines the exact error messages, but most tests are written on Linux systems with en_US locales. Other systems provide slightly different error messages which doesn't have a functional difference but makes the tests fail. Some operating systems provide different locales, behaving differently, too. Also some tests, test unpecified or wrong implementations by Linux libraries. As Solaris 11 switched more to Open Source libraries in some areas instead of having commercial clones (well technically GNU libs are often clones and Solaris libs were based on original Unix libraries...) this improved a bit from that side. Please mind that PHP is developed mostly on a volunteer basis and the work is focused on primarily used platforms. If you want to provide productive help we'd love having people going through those and provide fixes for overly specific tests and identifying broken PHP features. johannes -- Johannes Schlüter, MySQL Engineering, ORACLE Deutschland B.V. Co KG The above message represents my personal opinion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
Hi! As for the odd test failing, I see this : That looks like a lot of failures in most basic scripts. I suspect there's some unifying problem to that - what are the .diff files for some of these failures, is there anything interesting in the PHP error log? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
We focus those resources on the platforms used by 95% of our users. Feel free to dig in and send us some patches. Needless to say, all of those tests pass on Linux, FreeBSD and likely OSX as well. I will try that theory out on RHEL 6.3 and let you know. PHP is hardly what I would call fragile. Our QA process is rather intensive I think. In addition to the operating systems Rasmus mentioned, a lot of work goes into making sure they pass on Windows as well. I just tried a simply build on RHEL 6 and see this : TIME END 2013-01-16 01:11:10 = TEST RESULT SUMMARY - Exts skipped: 51 Exts tested : 26 - Number of tests : 12276 8329 Tests skipped : 3947 ( 32.2%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:2 ( 0.0%) ( 0.0%) Expected fail : 36 ( 0.3%) ( 0.4%) Tests passed: 8291 ( 67.5%) ( 99.5%) - Time taken : 654 seconds = = EXPECTED FAILED TEST SUMMARY - Test open_basedir configuration [tests/security/open_basedir_linkinfo.phpt] XFAIL REASON: BUG: open_basedir cannot delete symlink to prohibited file. See also bugs 48111 and 52176. Inconsistencies when accessing protected members [Zend/tests/access_modifiers_008.phpt] XFAIL REASON: Discussion: http://marc.info/?l=php-internalsm=120221184420957w=2 Inconsistencies when accessing protected members - 2 [Zend/tests/access_modifiers_009.phpt] XFAIL REASON: Discussion: http://marc.info/?l=php-internalsm=120221184420957w=2 Bug #48770 (call_user_func_array() fails to call parent from inheriting class) [Zend/tests/bug48770.phpt] XFAIL REASON: See Bug #48770 Bug #48770 (call_user_func_array() fails to call parent from inheriting class) [Zend/tests/bug48770_2.phpt] XFAIL REASON: See Bug #48770 Bug #48770 (call_user_func_array() fails to call parent from inheriting class) [Zend/tests/bug48770_3.phpt] XFAIL REASON: See Bug #48770 Bug #63336 (invalid E_NOTICE error occur) [Zend/tests/bug63336.phpt] XFAIL REASON: Bug is not fixed yet Initial value of static var in method depends on the include time of the class definition [Zend/tests/method_static_var.phpt] XFAIL REASON: Maybe not a bug DateTime::add() -- fall type2 type3 [ext/date/tests/DateTime_add-fall-type2-type3.phpt] XFAIL REASON: Various bugs exist DateTime::add() -- fall type3 type2 [ext/date/tests/DateTime_add-fall-type3-type2.phpt] XFAIL REASON: Various bugs exist DateTime::add() -- fall type3 type3 [ext/date/tests/DateTime_add-fall-type3-type3.phpt] XFAIL REASON: Various bugs exist DateTime::add() -- spring type2 type3 [ext/date/tests/DateTime_add-spring-type2-type3.phpt] XFAIL REASON: Various bugs exist DateTime::add() -- spring type3 type2 [ext/date/tests/DateTime_add-spring-type3-type2.phpt] XFAIL REASON: Various bugs exist DateTime::add() -- spring type3 type3 [ext/date/tests/DateTime_add-spring-type3-type3.phpt] XFAIL REASON: Various bugs exist DateTime::diff() -- fall type2 type3 [ext/date/tests/DateTime_diff-fall-type2-type3.phpt] XFAIL REASON: Various bugs exist DateTime::diff() -- fall type3 type2 [ext/date/tests/DateTime_diff-fall-type3-type2.phpt] XFAIL REASON: Various bugs exist DateTime::diff() -- fall type3 type3 [ext/date/tests/DateTime_diff-fall-type3-type3.phpt] XFAIL REASON: Various bugs exist DateTime::diff() -- spring type2 type3 [ext/date/tests/DateTime_diff-spring-type2-type3.phpt] XFAIL REASON: Various bugs exist DateTime::diff() -- spring type3 type2 [ext/date/tests/DateTime_diff-spring-type3-type2.phpt] XFAIL REASON: Various bugs exist DateTime::diff() -- spring type3 type3 [ext/date/tests/DateTime_diff-spring-type3-type3.phpt] XFAIL REASON: Various bugs exist DateTime::sub() -- fall type2 type3 [ext/date/tests/DateTime_sub-fall-type2-type3.phpt] XFAIL REASON: Various bugs exist DateTime::sub() -- fall type3 type2 [ext/date/tests/DateTime_sub-fall-type3-type2.phpt] XFAIL REASON: Various bugs exist DateTime::sub() -- fall type3 type3 [ext/date/tests/DateTime_sub-fall-type3-type3.phpt] XFAIL REASON: Various bugs exist DateTime::sub() -- spring type2 type3 [ext/date/tests/DateTime_sub-spring-type2-type3.phpt] XFAIL REASON: Various bugs exist DateTime::sub() -- spring type3 type2 [ext/date/tests/DateTime_sub-spring-type3-type2.phpt] XFAIL REASON: Various bugs exist DateTime::sub() -- spring type3 type3 [ext/date/tests/DateTime_sub-spring-type3-type3.phpt] XFAIL REASON: Various bugs exist Bug #53437 (Crash when using unserialized DatePeriod instance)
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
Please mind that PHP is developed mostly on a volunteer basis and the work is focused on primarily used platforms. If you want to provide productive help we'd love having people going through those and provide fixes for overly specific tests and identifying broken PHP features. I have a slew of Solaris servers and a new Niagara box and I guess I'll be working on this for a while. Also, I do everything with LC_ALL=C and am using Oracle Studio 12.3 as the compiler. I could switch over to gcc 4.7.2 if you think that would make a difference. Also .. I see buckets of warnings about prototype mismatch for argument data types. Not really production but I could hack at those. Really, the failures are the big concern here. Dennis ps: would be cool if PHP were a commercial grade release in the same way that MySQL has become a commercial grade product. Just dreaming. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
Hi! As for the odd test failing, I see this : That looks like a lot of failures in most basic scripts. I suspect there's some unifying problem to that - what are the .diff files for some of these failures, is there anything interesting in the PHP error log? I will try to wade through the logs tomorrow. At the moment I am doing the same process on RHEL and seeing a bucket of failures also. so really .. I see some work ahead to get a clean build. Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
Hi! I will try to wade through the logs tomorrow. At the moment I am doing the same process on RHEL and seeing a bucket of failures also. RHEL shouldn't have failures in core, though some extension tests may fail (unfortunately, error messages change or library versions change can trip up some modules). Do you have test results file (it is generated at the end of make test if you ask to save test results)? Could be useful to look into it and see what exactly fails. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On 01/15/2013 09:07 PM, Dennis Clarke wrote: Number of tests : 12276 8329 Tests skipped : 3947 ( 32.2%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:2 ( 0.0%) ( 0.0%) Expected fail : 36 ( 0.3%) ( 0.4%) Tests passed: 8291 ( 67.5%) ( 99.5%) Right, so 8291 tests passed and 2 failed. That's pretty close to clean on RHEL 6. The expected fails are ones we know are failing and are work-in-progress things. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On 01/15/2013 06:18 PM, Stas Malyshev wrote: Hi! I will try to wade through the logs tomorrow. At the moment I am doing the same process on RHEL and seeing a bucket of failures also. This URL has some potential to help, since it will show common failures other people are seeing: http://qa.php.net/reports/ RHEL shouldn't have failures in core, though some extension tests may fail (unfortunately, error messages change or library versions change can trip up some modules). Do you have test results file (it is generated at the end of make test if you ask to save test results)? Could be useful to look into it and see what exactly fails. Looking at RH's source RPM [1] for building PHP, you can see they typically update several expected PHP extension logs to make their build run 100% clean. This is just another data point about the large number of environments that PHP runs under, each of which can cause test result differences. Chris [1] You can see the equivalent at http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/ -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
