Re: [PHP-DEV] PHP 5.4.10 can not build Zend/PHP parsers with bison 2.6.5
On Tue, Jan 15, 2013 at 9:05 PM, Dennis Clarke dcla...@blastwave.orgwrote: Unless you are hacking PHP you can ignore Bison. Check the Makefile Well, the configure output claims that something is wrong, therefore the build can not be trusted. I'm just following the defacto way to build PHP and if the configure output claims something is wrong .. then it is wrong by definition. for where it is used. The PHP distribution contains Zend/zend_language_parser.[ch] and php-5.5/Zend/zend_ini_parser.[ch] already built from their respective .y files so bison is not generally invoked when building PHP. configure claims otherwise. Of course, if 2.6.5 is verified than it should be added to bison_version_list in Zend/acinclude.m4. Feel free to regenerate the parsers with it, review the test suite results, and create a github pull request. do what ? I access the release source tarball only. gcc-spec_node002 $ digest -a sha1 /usr/local/src/php-5.4.10.tar.gz 6be6a1c16ca3f6bec93d19ce5d6b94c5cf89373b That is the only php sources I am allowed to use. Anything else is not release and therefore not to be used on prod servers. I think we should retire this silly check, as it needs updating every time there is a new version. Instead, we should blacklist versions that *don't* work. Well bison 2.6.5 passes all of its own tests and therefore seems to be okay for prod. I would think that a PHP release would build more or less out of the box without any changes to the source tarball. If PHP can not be built from the release tarball with the typical GNU toolchain then .. it can't be built. I just tick off a box on the build sheet here as does not build in compliance with defacto standard rules and it goes back onto the update at some point pile. currently we have a whitelist for supported bison versions: http://lxr.php.net/xref/PHP_5_4/Zend/acinclude.m4#6 anything else will be reported, but this doesn't mean that php wouldn't compile with that, it can also mean that nobody tested and made sure that it works. this is why Derick mentioned that he thinks we should switch to a blacklist, so we only report the versions with known problems. ps: your passive aggressive tone doesn't really help your case here. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: Fix for duplicate magic methods calls (bug #63462)
Hi Stas, I think the patch is correct and should be committed into 5.3 and above. Thanks. Dmitry. On Mon, Jan 14, 2013 at 12:20 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I made a fix for bug #63462 - https://github.com/php/php-src/pull/258 - which changes a bit how we do guards by unmangling the names before applying guards. This is a slight change of behavior and also means that all private vars with the same name would use the same guard (all protected and public vars with the same name are the same var anyway, so they should be doing it in any case). Since it's a behavior change in core, I'd appreciate a second pair of eyes to see if nothing is broken by it. All tests pass but better safe then sorry. If no problems found in it, I'll commit it soon. Thanks, -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
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
Re: [PHP-DEV] PHP 5.4.10 can not build Zend/PHP parsers with bison 2.6.5
On 01/15/2013 12:09 PM, Dennis Clarke wrote: Of course, if 2.6.5 is verified than it should be added to bison_version_list in Zend/acinclude.m4. Feel free to regenerate the parsers with it, review the test suite results, and create a github pull request. Anything outside of release tarball won't be supported here. Sorry. However ... having said that, it is certainly worth the attempt. Question for you, ever seen PHP build on Solaris 10 with mysql ( in /opt/mysql as per MySQL Release Engineering packages ) and have it pass its own testsuite? I rarely build on Solaris. Other messages in this thread mention how you can assist the PHP community in resolving any issues you do see. I see. Well I am not new to this and knew that there would be issues. The general modus operandi of most people is to ditch the problem OS and switch over to Red Hat or maybe SUSE but the software investment here is too great. The switch over would be long and costly etc etc etc. Also, there are financial institutions that still love their UNIX servers ( Solaris ) and are unlikely to let go anytime soon. Maybe you could have a word with the executive board at Oracle and get them to stop making newer bigger Sparc servers and exadata storage? ;-) Are you building a specific PHP version for a reason? Can you use the pre-built Solaris PHP packages in some situations (e.g. see the Solaris chapter in http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html) I was not aware that Oracle had pre-built PHP packages. I can only assume that they would install with typical SVR4 packages into Solaris 10 and then be subject to maintenance under a typical MOS contract? If not, then I am stuck doing the port work myself. As for the version, well, the production release version seems like a good way to go. That seems to be PHP 5.4.10 at the moment and unless someone says that it is bleeding edge beta grade ... it makes sense to compile it. I am going to go check out your link there and, perhaps, stay in touch. from what I gather by reading between the lines no one is in a hurry at Oracle to do anything on Solaris either. At least, seems that way. Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.10 can not build Zend/PHP parsers with bison 2.6.5
currently we have a whitelist for supported bison versions: http://lxr.php.net/xref/PHP_5_4/Zend/acinclude.m4#6 anything else will be reported, but this doesn't mean that php wouldn't compile with that, it can also mean that nobody tested and made sure that it works. this is why Derick mentioned that he thinks we should switch to a blacklist, so we only report the versions with known problems. ps: your passive aggressive tone doesn't really help your case here. Yes, sorry about that. It was the end of a long day and I was on the last of the coffee and can be a jerk at times. I am generally a very productive jerk, but still a jerk. Sorry. I'll go an see if I can isolate those failures on Solaris and maybe triage a few things. Get a handle on what is really a concern and what is a wow, it needed GNU sed not XPG4 sed type of thing. Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Memory leak after calling exit() when Zend MM is turned off?
Hi internals! I am currently developing a Zend extension. Because the Zend MM leak reports are not really useful sometimes, I switched the memory manager off with the environment variable USE_ZEND_ALLOC=0, so that I can use valgrind. Right now I have found some kind of memory leak. You can use every script which has an exit()-call to reproduce this leak. For example: ?php exit(Memory leak example.\n); ? If you run this PHP script with valgrind, it will report some ugly memory leak: valgrind version: valgrind-3.6.0.SVN-Debian PHP Version: 5.4.10 (debug) Configure options: --disable-all --disable-cgi --enable-debug --- Command: export USE_ZEND_ALLOC=0 valgrind --leak-check=full php-5.4.10-debug test.php --- Report: ==5693== HEAP SUMMARY: ==5693== in use at exit: 420 bytes in 4 blocks ==5693== total heap usage: 8,355 allocs, 8,351 frees, 2,503,705 bytes allocated ==5693== ==5693== 420 (240 direct, 180 indirect) bytes in 1 blocks are definitely lost in loss record 4 of ==5693==at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==5693==by 0x5E08C4: _emalloc (zend_alloc.c:2423) ==5693==by 0x5C11C3: compile_file (zend_language_scanner.l:551) ==5693==by 0x617311: zend_execute_scripts (zend.c:1301) ==5693==by 0x58A22F: php_execute_script (main.c:2482) ==5693==by 0x768967: do_cli (php_cli.c:988) ==5693==by 0x76987C: main (php_cli.c:1364) ==5693== ==5693== LEAK SUMMARY: ==5693==definitely lost: 240 bytes in 1 blocks ==5693==indirectly lost: 180 bytes in 3 blocks ==5693== possibly lost: 0 bytes in 0 blocks ==5693==still reachable: 0 bytes in 0 blocks ==5693== suppressed: 0 bytes in 0 blocks When the Zend memory manager is turned on, everything is fine. Is this behavior intended? Thanks in advance, Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak after calling exit() when Zend MM is turned off?
On 01/16/2013 02:53 PM, Pascal Mathis wrote: When the Zend memory manager is turned on, everything is fine. Is this behavior intended? We do have some intentional leaks where we rely on the pool allocator to wipe things at the end of a request. So I am less concerned about things you see at request termination than I would be if you found one mid-request. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory leak after calling exit() when Zend MM is turned off?
On 16 בינו 2013, at 22:00, Pascal Mathis d...@snapserv.net wrote: Hi internals! I am currently developing a Zend extension. Because the Zend MM leak reports are not really useful sometimes, I switched the memory manager off with the environment variable USE_ZEND_ALLOC=0, so that I can use valgrind. Right now I have found some kind of memory leak. You can use every script which has an exit()-call to reproduce this leak. For example: ?php exit(Memory leak example.\n); ? If you run this PHP script with valgrind, it will report some ugly memory leak: valgrind version: valgrind-3.6.0.SVN-Debian PHP Version: 5.4.10 (debug) Configure options: --disable-all --disable-cgi --enable-debug --- Command: export USE_ZEND_ALLOC=0 valgrind --leak-check=full php-5.4.10-debug test.php --- Report: ==5693== HEAP SUMMARY: ==5693== in use at exit: 420 bytes in 4 blocks ==5693== total heap usage: 8,355 allocs, 8,351 frees, 2,503,705 bytes allocated ==5693== ==5693== 420 (240 direct, 180 indirect) bytes in 1 blocks are definitely lost in loss record 4 of ==5693==at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==5693==by 0x5E08C4: _emalloc (zend_alloc.c:2423) ==5693==by 0x5C11C3: compile_file (zend_language_scanner.l:551) ==5693==by 0x617311: zend_execute_scripts (zend.c:1301) ==5693==by 0x58A22F: php_execute_script (main.c:2482) ==5693==by 0x768967: do_cli (php_cli.c:988) ==5693==by 0x76987C: main (php_cli.c:1364) ==5693== ==5693== LEAK SUMMARY: ==5693==definitely lost: 240 bytes in 1 blocks ==5693==indirectly lost: 180 bytes in 3 blocks ==5693== possibly lost: 0 bytes in 0 blocks ==5693==still reachable: 0 bytes in 0 blocks ==5693== suppressed: 0 bytes in 0 blocks When the Zend memory manager is turned on, everything is fine. Is this behavior intended? Yes. The implementation of exit() will not necessarily free all allocated blocks. It therefore intentionally suppresses errors that might come from the memory manager regarding leaks - but if you turn off the memory manager and use valgrind - you'd see them. It's not a problem unless you actually use PHP without the memory manager in production, which of course you should not. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] zend_parse_parameters() improvements
On Wed, 09 Jan 2013 17:19:10 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: I've opened voting for the zend_parse_parameters() improvements RFC. You can now go to https://wiki.php.net/rfc/zpp_improv#voting The RFC was unanimously accepted. I've merged it to 5.5 in b8603035. Thank you. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] zend_parse_parameters() improvements
On Wed, Jan 16, 2013 at 11:41 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: On Wed, 09 Jan 2013 17:19:10 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: I've opened voting for the zend_parse_parameters() improvements RFC. You can now go to https://wiki.php.net/rfc/zpp_**improv#votinghttps://wiki.php.net/rfc/zpp_improv#voting The RFC was unanimously accepted. I've merged it to 5.5 in b8603035. Thank you. Cool! Thanks for your work on this! Nikita
[PHP-DEV] Re: [PHP-CVS] com php-src: Bug #63699: performance improvements for varios ext/date functions: NEWS ext/date/php_date.c ext/date/php_date.h
[CC'ing internals.]
On 01/16/2013 03:15 PM, Paul Taulborg wrote:
On Wed, Jan 16, 2013 at 4:21 PM, Nuno Lopes nlop...@php.net wrote:
On Thu, Jan 10, 2013 at 4:59 PM, Nuno Lopes nlop...@php.net wrote:
On 01/07/2013 07:27 AM, Paul Taulborg wrote:
I would love to write this patch, I'm all in favor of simplifying
this. :) We should probably get with derick (cc'd) on this as well, to
make sure something else obvious isn't being missed.
Let me know how you want me to proceed. Thanks :)
Paul,
For small changes submit bugs (and/or github pull requests) like you
did before.
For bigger changes, start an RFC at https://wiki.php.net/rfc
This will help focus the change, and provides a source for any doc
updates.
Since it is really just you and Derick looking at this area, be
prepared
to be a leader.
Don't forget to CC internals.
Chris
PS Note that Derick tends to ignore top-posted email.
Bug/patch submitted:
https://bugs.php.net/bug.php?id=63941
Will post on internals momentarily. Turns out removing
default_timezone entirely won't work due to the callback for ini_set,
but this isn't a major problem. We could probably remove it entirely
with a future patch, but it would require some other internal variable
somewhere along the line anyway.
I have another suggestion that avoids BC break. Pseudo-code:
guess_timezone():
if (timezone) return timezone
if (default_timezone) return default_timezone
return UTC
OnUpdate ini option:
if (valid) {
free(default_timezone)
default_timezone = new
}
PHP's date_default_timezone_set():
if (valid) {
free(timezone)
timezone = new
} else {
timezone = NULL
}
I belive this causes no major BC break and enables efficient code.
Note that according to the manual, date_default_timezone_set() takes
precedence over the ini setting, and therefore we cannot set the
'timezone'
var in the ini handler (as I previously wrongly suggested).
Nuno
Nuno,
Unless I'm misunderstanding or missing something here, this is already
what I did in the patch submitted 4 days ago:
https://bugs.php.net/bug.php?id=63941
I'm still waiting for feedback and for the patch to be applied.
Thanks
Sorry for the delay, but I've been quite busy..
So, to answer your question: I don't think your patch implements the
pseudo-code I suggested above. In particular your patch change the
documented behaviour for intermixed ini_set/date_set_default_tz calls.
Nuno
I would recommend this be changed, and it would not conflict with the
documentation. First, the ini_set() does not say this will not
override date_set_default_timezone(), even though that is the
functionality. A user could easily presume (wrongly), that both do the
same thing (and they should, for consistency). I see no logical reason
to have two values in the core, that do the same thing.
For instance, I could use date_set_default_timezone() in one spot,
then later ini_set, expecting it to override, but it doesn't. This is
an extra nuance for no gain. If the argument is but I might want to
revert back to the ini value!, well, you can't currently without a
literal ini_get() and then another date_set_default_timezone() call.
This is no different than what my patch does, you would have to grab
the original value with ini_get, and then set it via EITHER method.
This simplifies the internal code handling and makes it more
consistent and makes the code a bit easier to follow with regards to
this particular subset of the date section.
If we're going to get in here and start optimizing code, we should do
so, not continue to throw band-aids on that do nothing in terms of
performance gains or code readability/manageability. That is the
reason I tackled this head-on in the way I did, because having both
values internally checked is not necessary. I cannot see any reason to
have two values internally to represent essentially the same thing. If
there is something I'm missing here regarding that, please let me
know.
Thanks
--
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
