Re: [PHP-DEV] About to end 5.3
Hi! Good bye 5.3, you were a great step for PHP! Looking forward to a bright and open future! Thank you Johannes for all you work on 5.3! -- 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] Disabling the GC during shutdown
On Thu, Jun 20, 2013 at 1:46 AM, Anthony Ferrara ircmax...@gmail.com wrote: All, We were discussing a range of bugs today with the garbage collector. For example: https://bugs.php.net/bug.php?id=64827 After quite a bit of digging, it appears what's happening is that the garbage collector is running during the shutdown of PHP. So the destructors are fired, and the variables are being destroyed when the GC run happens. This means that the GC, while walking the variable tree runs into a partially destructed object (where an entry of the hash table has already been freed). This causes a segfault, and fun ensues. Hey: Sorry, but I don't this this explain is right. if there is more than one refcount to a zval, then it should never be freed and if a zval is freed, then it must also be removed from the gc roots. according to your explain, the gc segfault while walking through a hashtable of a object. but that doesn't make any sense, since if it segfault in walking, then it should also segfault when trying to free the hash table later while dtor the object. disable GC in shutdown is okey for me. but that is just try to cover the bug somewhere in the refcount handler.. not the right fix. thanks Under normal conditions (not during shutdown), this does not appear to be an issue, because the zval is destructed prior to the object destruction. This means that there should never be a case where the GC hits a partially freed object during normal execution. From what I can see, there are two possible fixes. The first would be to change how object destruction works in the first place, to tie the variable into the destruction process (basically refactor the object delref API to also accept the current zval). That way the part of the code that makes the decision to nuke the object can nuke the zval first (and hence prevent this condition). However, this is a major API change and would effect a lot of extensions that are using or tieing into this hook. The other option would be to simply disable the GC on shutdown. Considering all of the variables are going to be thrown away anyway, having the GC run during shutdown seems a bit wasteful anyway. So if we can kill two birds with one stone, why not? I've prepared a basic patch: https://github.com/ircmaxell/php-src/compare/gc_deactivate_on_shutdown I did confirm with odoucet (one of the original reporters) that this does clear up his issue: https://gist.github.com/odoucet/5796378 (along with trying a bunch of other things). There are a few out standing questions though: 1. Technically, all we need to do is force GC_G(gc_enabled) = 0 in shutdown. But we could also use zend_alter_ini_entry which has the same effect. The question comes is there any reason to go through the overhead of altering the ini entry instead of the global directly? We do access the global directly in other areas (but it's typically only set via ini)... 2. I put it in php_request_shutdown() after deactivate_ticks, but before it calls shutdown functions. I could see it being moved after the shutdown function call, but I'm not sure if it's worth it (either way). thoughts? 3. Can anyone think of a reason we'd want the GC enabled during the request shutdown? I can't think of any... Additionally, considering that this does solve a segfault, is it worth nominating this for 5.3? Or is it too risky (or something else I'm missing)... Thanks, Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disabling the GC during shutdown
On Thu, Jun 20, 2013 at 6:12 PM, Laruence larue...@php.net wrote: On Thu, Jun 20, 2013 at 1:46 AM, Anthony Ferrara ircmax...@gmail.com wrote: All, We were discussing a range of bugs today with the garbage collector. For example: https://bugs.php.net/bug.php?id=64827 After quite a bit of digging, it appears what's happening is that the garbage collector is running during the shutdown of PHP. So the destructors are fired, and the variables are being destroyed when the GC run happens. This means that the GC, while walking the variable tree runs into a partially destructed object (where an entry of the hash table has already been freed). This causes a segfault, and fun ensues. Hey: Sorry, but I don't this this explain is right. if there is more than one refcount to a zval, then it should never be freed and if a zval is freed, then it must also be removed from the gc roots. according to your explain, the gc segfault while walking through a hashtable of a object. but that doesn't make any sense, since if it segfault in walking, then it should also segfault when trying to free the hash table later while dtor the object. disable GC in shutdown is okey for me. but that is just try to cover the bug somewhere in the refcount handler.. not the right fix. thanks And actually, I prefer not doing this(disable gc in shutdown) for now, because maybe someday we can get a simple reproduce script(as we all have see, it is very rare). then the segfault will be fixed, in the right way. thanks Under normal conditions (not during shutdown), this does not appear to be an issue, because the zval is destructed prior to the object destruction. This means that there should never be a case where the GC hits a partially freed object during normal execution. From what I can see, there are two possible fixes. The first would be to change how object destruction works in the first place, to tie the variable into the destruction process (basically refactor the object delref API to also accept the current zval). That way the part of the code that makes the decision to nuke the object can nuke the zval first (and hence prevent this condition). However, this is a major API change and would effect a lot of extensions that are using or tieing into this hook. The other option would be to simply disable the GC on shutdown. Considering all of the variables are going to be thrown away anyway, having the GC run during shutdown seems a bit wasteful anyway. So if we can kill two birds with one stone, why not? I've prepared a basic patch: https://github.com/ircmaxell/php-src/compare/gc_deactivate_on_shutdown I did confirm with odoucet (one of the original reporters) that this does clear up his issue: https://gist.github.com/odoucet/5796378 (along with trying a bunch of other things). There are a few out standing questions though: 1. Technically, all we need to do is force GC_G(gc_enabled) = 0 in shutdown. But we could also use zend_alter_ini_entry which has the same effect. The question comes is there any reason to go through the overhead of altering the ini entry instead of the global directly? We do access the global directly in other areas (but it's typically only set via ini)... 2. I put it in php_request_shutdown() after deactivate_ticks, but before it calls shutdown functions. I could see it being moved after the shutdown function call, but I'm not sure if it's worth it (either way). thoughts? 3. Can anyone think of a reason we'd want the GC enabled during the request shutdown? I can't think of any... Additionally, considering that this does solve a segfault, is it worth nominating this for 5.3? Or is it too risky (or something else I'm missing)... Thanks, Anthony -- Laruence Xinchen Hui http://www.laruence.com/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disabling the GC during shutdown
Laruence, Sorry, but I don't this this explain is right. if there is more than one refcount to a zval, then it should never be freed and if a zval is freed, then it must also be removed from the gc roots. The point here is that the GC is run *while* the zval is being freed. Check out the backtrace here: https://bugs.php.net/bug.php?id=64827 , specifically zval pointer 0x272afb8 It appears 4 times recursively being passed into zend_objects_free_object_storage before the GC is triggered and it segfaults. according to your explain, the gc segfault while walking through a hashtable of a object. Yes, that is what's happening here. zval_mark_grey() is trying to walk through the object's hash table, but the first bucket is already freed, so when it tries to access it bad things happen. but that doesn't make any sense, since if it segfault in walking, then it should also segfault when trying to free the hash table later while dtor the object. That's the point. The dtor is already happening on that object when the GC tries to run over it again. disable GC in shutdown is okey for me. but that is just try to cover the bug somewhere in the refcount handler.. not the right fix. Looking back through, we still have the problem where we can't null out the zval before destructing the object (like we do with arrays) to prevent this. That's why I suggested one alternative would be to modify zend_objects_store_del_ref_by_handle_ex to also accept the zval, so it can be nulled if the object is going to be freed. However, we could set the object's bucket to invalid in the delref handler before we call free_storage. And then modify the GC to check for a valid bucket... I'll try that patch today to see if it solves the original issue (as it shouldn't result in an API change either)... Thanks for the thoughts... Anthony
Re: [PHP-DEV] Re: About to end 5.3
On 06/19/2013 10:08 PM, David Soria Parra wrote: On 2013-06-19, Johannes Schlüter johan...@php.net wrote: Good bye 5.3, you were a great step for PHP! Looking forward to a bright and open future! Thank you for taking care of this branch for so long. Keep the good job up. ditto! Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ARM performance and GOTO executor
Hello all, I am working on ARM server performance tuning, and I have been playing around a bit with the various executor modes and zend_vm_gen.php. As it turns out (scroll down for numbers), the GOTO executor is much faster than the default CALL executor on ARM, partly due to fewer branch mispredictions (as perf tells me) but there are probably other factors at play here as well. My question to you is if we could parametrize this in the build system, for instance by adding alternate files zend_vm_opcodes-goto.h and zend_vm_execute-goto.h to the tree, and selecting those when targeting ARM (and perhaps other archs that may prefer GOTO over CALL as well). Or is there a better way of including/selecting alternate executors? Also, when playing around, I noticed that building the executor without specialization is broken, as there are erroneous FREE_OP2() calls left behind in the handlers for 'break' and 'continue'. If nobody objects, I will remove them (zend_vm_def.h lines 3302 and 3314) Regards, Ard. ARM Cortex-A15 @ 1.7 GHz with default executor (specialized CALL) = simple 0.358 simplecall 0.396 simpleucall0.419 simpleudcall 0.458 mandel 0.839 mandel21.038 ackermann(7) 0.400 ary(5) 0.096 ary2(5)0.087 ary3(2000) 0.490 fibo(30) 1.157 hash1(5) 0.135 hash2(500) 0.096 heapsort(2)0.266 matrix(20) 0.309 nestedloop(12) 0.499 sieve(30) 0.363 strcat(20) 0.046 Total 7.449 Performance counter stats for 'php Zend/bench.php': 7444.535230 task-clock#0.983 CPUs utilized 103 context-switches #0.014 K/sec 9 cpu-migrations#0.001 K/sec 5963 page-faults #0.801 K/sec 12728701964 cycles#1.710 GHz 13603248229 instructions #1.07 insns per cycle 2633774500 branches # 353.786 M/sec 118799433 branch-misses #4.51% of all branches 7.570311211 seconds time elapsed ARM Cortex-A15 @ 1.7 GHz with specialized GOTO executor === simple 0.185 simplecall 0.295 simpleucall0.249 simpleudcall 0.257 mandel 0.349 mandel20.529 ackermann(7) 0.252 ary(5) 0.061 ary2(5)0.060 ary3(2000) 0.393 fibo(30) 0.798 hash1(5) 0.092 hash2(500) 0.079 heapsort(2)0.195 matrix(20) 0.206 nestedloop(12) 0.214 sieve(30) 0.241 strcat(20) 0.025 Total 4.479 Performance counter stats for '~/php Zend/bench.php': 4468.040559 task-clock#0.983 CPUs utilized 79 context-switches #0.018 K/sec 9 cpu-migrations#0.002 K/sec 5062 page-faults #0.001 M/sec 7561345552 cycles#1.692 GHz 11297962039 instructions #1.49 insns per cycle 2121936756 branches # 474.914 M/sec 22190686 branch-misses #1.05% of all branches 4.545350085 seconds time elapsed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ARM performance and GOTO executor
GOTO-executor is faster on x86 as well. It may be proven by synthetic benchmarks, however. on real-life applications it doesn't make any significant difference (sometimes it even slowdown). I'm not sure how we should generate (and test) zend_vm_execute-goto.h. Probably the only good option is generating all the different executors at once and may be even linking them all together to select one at run-time. FREE_OP2() in BRK/CONT my be removed. Thanks. Dmitry. On Thu, Jun 20, 2013 at 5:55 PM, Ard Biesheuvel ard.biesheu...@linaro.orgwrote: Hello all, I am working on ARM server performance tuning, and I have been playing around a bit with the various executor modes and zend_vm_gen.php. As it turns out (scroll down for numbers), the GOTO executor is much faster than the default CALL executor on ARM, partly due to fewer branch mispredictions (as perf tells me) but there are probably other factors at play here as well. My question to you is if we could parametrize this in the build system, for instance by adding alternate files zend_vm_opcodes-goto.h and zend_vm_execute-goto.h to the tree, and selecting those when targeting ARM (and perhaps other archs that may prefer GOTO over CALL as well). Or is there a better way of including/selecting alternate executors? Also, when playing around, I noticed that building the executor without specialization is broken, as there are erroneous FREE_OP2() calls left behind in the handlers for 'break' and 'continue'. If nobody objects, I will remove them (zend_vm_def.h lines 3302 and 3314) Regards, Ard. ARM Cortex-A15 @ 1.7 GHz with default executor (specialized CALL) ==**==**= simple 0.358 simplecall 0.396 simpleucall0.419 simpleudcall 0.458 mandel 0.839 mandel21.038 ackermann(7) 0.400 ary(5) 0.096 ary2(5)0.087 ary3(2000) 0.490 fibo(30) 1.157 hash1(5) 0.135 hash2(500) 0.096 heapsort(2)0.266 matrix(20) 0.309 nestedloop(12) 0.499 sieve(30) 0.363 strcat(20) 0.046 Total 7.449 Performance counter stats for 'php Zend/bench.php': 7444.535230 task-clock#0.983 CPUs utilized 103 context-switches #0.014 K/sec 9 cpu-migrations#0.001 K/sec 5963 page-faults #0.801 K/sec 12728701964 cycles#1.710 GHz 13603248229 instructions #1.07 insns per cycle 2633774500 branches # 353.786 M/sec 118799433 branch-misses #4.51% of all branches 7.570311211 seconds time elapsed ARM Cortex-A15 @ 1.7 GHz with specialized GOTO executor ==**= simple 0.185 simplecall 0.295 simpleucall0.249 simpleudcall 0.257 mandel 0.349 mandel20.529 ackermann(7) 0.252 ary(5) 0.061 ary2(5)0.060 ary3(2000) 0.393 fibo(30) 0.798 hash1(5) 0.092 hash2(500) 0.079 heapsort(2)0.195 matrix(20) 0.206 nestedloop(12) 0.214 sieve(30) 0.241 strcat(20) 0.025 Total 4.479 Performance counter stats for '~/php Zend/bench.php': 4468.040559 task-clock#0.983 CPUs utilized 79 context-switches #0.018 K/sec 9 cpu-migrations#0.002 K/sec 5062 page-faults #0.001 M/sec 7561345552 cycles#1.692 GHz 11297962039 instructions #1.49 insns per cycle 2121936756 branches # 474.914 M/sec 22190686 branch-misses #1.05% of all branches 4.545350085 seconds time elapsed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Attend the Premier Annual Conference Tradeshow for Venue Managers - FREE
Celebrity Access and the International Association of Venue Managers (IAVM) invite you to the 88th annual VenueConnect, taking place July 27-30, 2013 in legendary New Orleans, La. Noted as the premier conference and trade show for venue professionals, VenueConnect is the largest convention for industry professionals from all venue types and provides education, inspiration, and networking opportunities that cant be found anywhere else. This year the IAVM DirectConnect Appointment Program will launch at VenueConnect. Venue professionals who qualify for DirectConnect will receive FREE conference registration and 2 night hotel accommodations. Its easy to qualify! Simply apply here by Thursday, June 27 it only takes 10-15 minutes to apply. If you qualify, youll receive instructions on setting your appointments (10 brief meetings the morning of July 29 at VenueConnect) and IAVM will cover your conference registration and 2 nights hotel fees. For more information and important VenueConnect links, click here. We look forward to seeing you in New Orleans! If you choose not to receive future emails, please reply with Remove in the Subject Line.
[PHP-DEV] PHP 5.3.18RC1 and 5.4.8RC1 Released for Testing!
Hi! We've released PHP 5.3.27RC1 and 5.4.17RC1 which can be found here: 5.3.27RC1: http://downloads.php.net/johannes/php-5.3.27RC1.tar.bz2 http://downloads.php.net/johannes/php-5.3.27RC1.tar.gz 5.4.17RC1: http://downloads.php.net/stas/php-5.4.17RC1.tar.bz2 http://downloads.php.net/stas/php-5.4.17RC1.tar.gz Windows binaries for both as always are at: http://windows.php.net/qa/ These are release candidates for regular bugfix releases, the full list of issues fixed can be found in the NEWS files. Please test and report if anything is broken. Mind that PHP 5.3.27 is supposed to be the last regular PHP 5.3 release before entering in extended support providing security fixes only. Please double check there is nothing broken in it. If no critical issues are found in these RCs, the final versions will be released in two weeks. Regards, Stas Malyshev Johannes Schlüter PHP 5.4 Release Master PHP 5.3 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.27RC1 and 5.4.17RC1 Released for Testing!
Hi! We've released PHP 5.3.27RC1 and 5.4.17RC1 which can be found here: 5.3.27RC1: http://downloads.php.net/johannes/php-5.3.27RC1.tar.bz2 http://downloads.php.net/johannes/php-5.3.27RC1.tar.gz 5.4.17RC1: http://downloads.php.net/stas/php-5.4.17RC1.tar.bz2 http://downloads.php.net/stas/php-5.4.17RC1.tar.gz Windows binaries for both as always are at: http://windows.php.net/qa/ These are release candidates for regular bugfix releases, the full list of issues fixed can be found in the NEWS files. Please test and report if anything is broken. Mind that PHP 5.3.27 is supposed to be the last regular PHP 5.3 release before entering in extended support providing security fixes only. Please double check there is nothing broken in it. If no critical issues are found in these RCs, the final versions will be released in two weeks. Regards, Stas Malyshev Johannes Schlüter PHP 5.4 Release Master PHP 5.3 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: OPCache documentation
On Wed, May 15, 2013 at 3:54 PM, Julien Pauli jpa...@php.net wrote: Hi all, As you know, 5.5 final is coming soon. We are in RC, so mainly stabilizing stuff and preparing the final release for anyone to setup 5.5 on their servers. I see the documentation migration guide has already been commited, that's a good new. I also see that new features we ship in 5.5 are online in the documentation, great ! But a crucial feature is missing doc : OPCache. As this feature is a very big step in PHP's life (we finally have a recommanded, bundled opcode cache system, and I'm very proud of this personnaly), I think it is crucial to have a good documentation about it. Has anyone started to write some doc about OPCache ? Another subject is APC. We have its doc on php.net, all right. What I would like is we patch APC doc when 5.5 final gets released, to clearly show our mind about it. That way, any people using 5.5 should be able to read in the doc that APC has support has been interrupted, that APC should never be used together with OPCache, and that OPCache is now the standard recommanded OPCode caching solution for 5.5, 5.4 and 5.3. It is crucial to communicate one this point for our users. Then will come the User cache debate Thank you. Up. Could we at least plan such a project ? 5.5 is released now. I know we are still having trouble about OpCache particulary under Windows. I dont shadow that. I would just like we start thinking about writing documentation for OPCache features and merge them to our official documentation. If it's already planned by someone, just let me know ;-) Thx. Julien.Pauli
Re: [PHP-DEV] PHP 5.5.0 final has been released!
Congrats all!!! On Thu, Jun 20, 2013 at 5:22 PM, Julien Pauli jpa...@php.net wrote: Hello! The PHP Development Team would like to announce the immediate release of PHP 5.5.0. This release includes a large number of new features and bug fixes. A separate release announcement is also available. For changes in PHP 5.5.0 since PHP 5.4, please consult the PHP 5 ChangeLog. Release Announcement: http://www.php.net/release_5_5_0.php Downloads:http://www.php.net/downloads.php#v5.5 Changelog:http://www.php.net/ChangeLog-5.php#5.5.0 Thanks to all contributors that made this new version available. regards, David Soria Parra Julien Pauli
Re: [PHP-DEV] PHP 5.5.0 final has been released!
Congrats!!! -- Nick Wallace On Thu, Jun 20, 2013 at 4:39 PM, Anthony Ferrara ircmax...@gmail.com wrote: Congrats all!!! On Thu, Jun 20, 2013 at 5:22 PM, Julien Pauli jpa...@php.net wrote: Hello! The PHP Development Team would like to announce the immediate release of PHP 5.5.0. This release includes a large number of new features and bug fixes. A separate release announcement is also available. For changes in PHP 5.5.0 since PHP 5.4, please consult the PHP 5 ChangeLog. Release Announcement: http://www.php.net/release_5_5_0.php Downloads:http://www.php.net/downloads.php#v5.5 Changelog:http://www.php.net/ChangeLog-5.php#5.5.0 Thanks to all contributors that made this new version available. regards, David Soria Parra Julien Pauli -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: OPCache documentation
On Thu, Jun 20, 2013 at 5:36 PM, Julien Pauli jpa...@php.net wrote: On Wed, May 15, 2013 at 3:54 PM, Julien Pauli jpa...@php.net wrote: Hi all, As you know, 5.5 final is coming soon. We are in RC, so mainly stabilizing stuff and preparing the final release for anyone to setup 5.5 on their servers. I see the documentation migration guide has already been commited, that's a good new. I also see that new features we ship in 5.5 are online in the documentation, great ! But a crucial feature is missing doc : OPCache. As this feature is a very big step in PHP's life (we finally have a recommanded, bundled opcode cache system, and I'm very proud of this personnaly), I think it is crucial to have a good documentation about it. Has anyone started to write some doc about OPCache ? Another subject is APC. We have its doc on php.net, all right. What I would like is we patch APC doc when 5.5 final gets released, to clearly show our mind about it. That way, any people using 5.5 should be able to read in the doc that APC has support has been interrupted, that APC should never be used together with OPCache, and that OPCache is now the standard recommanded OPCode caching solution for 5.5, 5.4 and 5.3. It is crucial to communicate one this point for our users. Then will come the User cache debate Thank you. Up. Could we at least plan such a project ? 5.5 is released now. I know we are still having trouble about OpCache particulary under Windows. I dont shadow that. I would just like we start thinking about writing documentation for OPCache features and merge them to our official documentation. If it's already planned by someone, just let me know ;-) I find it hard to believe this feature made it into 5.5.0 without a shred of documentation. I would be willing to help, but I actually don't know much about how opcache works. If anyone is willing to give me a hand I could draft up some basic FAQ style docs at least so that 5.5.0 users will have some point of reference. Thx. Julien.Pauli
[PHP-DEV] Re: [PHP-DOC] Re: OPCache documentation
On 20 June 2013 14:36, Julien Pauli jpa...@php.net wrote: On Wed, May 15, 2013 at 3:54 PM, Julien Pauli jpa...@php.net wrote: Hi all, As you know, 5.5 final is coming soon. We are in RC, so mainly stabilizing stuff and preparing the final release for anyone to setup 5.5 on their servers. I see the documentation migration guide has already been commited, that's a good new. I also see that new features we ship in 5.5 are online in the documentation, great ! But a crucial feature is missing doc : OPCache. As this feature is a very big step in PHP's life (we finally have a recommanded, bundled opcode cache system, and I'm very proud of this personnaly), I think it is crucial to have a good documentation about it. Has anyone started to write some doc about OPCache ? Another subject is APC. We have its doc on php.net, all right. What I would like is we patch APC doc when 5.5 final gets released, to clearly show our mind about it. That way, any people using 5.5 should be able to read in the doc that APC has support has been interrupted, that APC should never be used together with OPCache, and that OPCache is now the standard recommanded OPCode caching solution for 5.5, 5.4 and 5.3. It is crucial to communicate one this point for our users. Then will come the User cache debate Thank you. Up. Could we at least plan such a project ? 5.5 is released now. I know we are still having trouble about OpCache particulary under Windows. I dont shadow that. I would just like we start thinking about writing documentation for OPCache features and merge them to our official documentation. If it's already planned by someone, just let me know ;-) I'm working on some basic opcache documentation as we speak, since it was pointed out on #php.doc. That said, mostly what I'm doing for now is adapting the README in ext/opcache and documenting opcache_reset() and opcache_invalidate() — some additional theory of operating and setup documentation would be very welcome. There should be something to look at in SVN in the next hour or so. My apologies — I wrote the first draft of the migration guide in the mid alpha stage (ie before opcache was merged) of 5.5 with the intention of going back to flesh it out before the final release, but time has been a bit of an issue. Turns out moving halfway across the world is a real time sink. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5.0 final has been released!
Hello! The PHP Development Team would like to announce the immediate release of PHP 5.5.0. This release includes a large number of new features and bug fixes. A separate release announcement is also available. For changes in PHP 5.5.0 since PHP 5.4, please consult the PHP 5 ChangeLog. Release Announcement: http://www.php.net/release_5_5_0.php Downloads:http://www.php.net/downloads.php#v5.5 Changelog:http://www.php.net/ChangeLog-5.php#5.5.0 Thanks to all contributors that made this new version available. regards, David Soria Parra Julien Pauli
Re: [PHP-DEV] Disabling the GC during shutdown
Hi! Yes, that is what's happening here. zval_mark_grey() is trying to walk through the object's hash table, but the first bucket is already freed, so when it tries to access it bad things happen. Why is this specific to shutdown? Hashtables are freed all the time, what specific shutdown is doing different from all others so that this bug only happens on shutdown? -- 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
[PHP-DEV] Re: [PHP-DOC] Re: OPCache documentation
On Thu, Jun 20, 2013 at 5:51 PM, Adam Harvey ahar...@php.net wrote: I'm working on some basic opcache documentation as we speak, since it was pointed out on #php.doc. That said, mostly what I'm doing for now is adapting the README in ext/opcache and documenting opcache_reset() and opcache_invalidate() — some additional theory of operating and setup documentation would be very welcome. There should be something to look at in SVN in the next hour or so. My apologies — I wrote the first draft of the migration guide in the mid alpha stage (ie before opcache was merged) of 5.5 with the intention of going back to flesh it out before the final release, but time has been a bit of an issue. Turns out moving halfway across the world is a real time sink. Thank you for working on that. I will dig into opcache over the next few days and see if I can lend a hand. Adam
Re: [PHP-DEV] Disabling the GC during shutdown
Stas,
Why is this specific to shutdown? Hashtables are freed all the time,
what specific shutdown is doing different from all others so that this
bug only happens on shutdown?
Honestly, I am not sure. Every report that I've seen has it happening at
shutdown. Could very well be a coincidence.
As far as what's happening, figure out more.
Basically, zend_deactivate() (which gets fired long after destructors)
tries to destroy the object store:
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#293
This iterates through the objects and tries to free them.
Well, during this process, any properties which are still alive are
dtor'ed. However, at a certain point, the garbage collector is fired.
That's when things get funky.
With the latest dump, what appears to be happening is that *something*
between the zend_deactivate call, and the GC being fired, is overwriting
one of the object zval's with *some* data. Here's a sample dump of the zval:
(gdb) print (zval_gc_info) *pz
$1 = {z = {value = {lval = 31337624, dval = 1.5482843440690148e-316,
str = {val = 0x1de2c98 0, len = 20823032}, ht = 0x1de2c98, obj = {
handle = 31337624, handlers = 0x13dbbf8}}, refcount__gc =
4294967295, type = 5 '\005', is_ref__gc = 0 '\000'}, u = {
buffered = 0x2, next = 0x2}}
As you can see, nasty. (Here's the full BT:
https://gist.github.com/odoucet/5796378#comment-848723 )
Well, when the GC hits that zval, it tries to access the object handle, and
throws a segfault (as it's WAY beyond the end of allocated memory).
I have a patch which prevents the segfault:
https://github.com/ircmaxell/php-src/compare/invalidate_object_on_dtor
However, that's not really fixing the situation either, as the zval is
still getting nuked (but only partially).
I am still trying to replicate the issue locally, and if I can, then I can
try to setup watches to check for what's overwriting the zval. But for now,
this is the current progress...
And no, I'm withdrawing the original concept of disabling the GC during
shutdown. The current patch I have works, but it's still just a bandaid on
a gunshot wound, and I'm going to try to figure out what's actually
overwriting the zval..
Anthony
Re: [PHP-DEV] PHP 5.5.0beta1 ZTS broken build
Hi guys, Cannot the patch be backported to 5.4? Because actually 5.4 allows build with Bison 2.6.1, but it doesn't work for ZTS build though. 2013/3/26 Pierre Joye pierre@gmail.com: On Mar 26, 2013 12:59 AM, Christopher Jones christopher.jo...@oracle.com wrote: OK. I also tested bison 2.7. After locally patching Zend/acinclude.m4 to allow 2.7, then the PHP 5.5 testsuite has only five fails, all in gd. Which? Should be max 2 (merge issue). -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Case insensitivity no longer locale specific
Hi Folks: I'd like to put an example in the 5.5 migration documentation for the Case insensitivity no longer locale specific section. Can someone please provide one? Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Case insensitivity no longer locale specific
Hi! I'd like to put an example in the 5.5 migration documentation for the Case insensitivity no longer locale specific section. Can someone please provide one? Some locales (Turkish one for example) have very unexpected rules of lowercasing and uppercasing - IIRC Turkish locale lowercases I into something else than i. Thus we moved engine functions from locale-dependent lowercasing to ASCII lowercasing - so SamIam is always lowercased to samiam. -- 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] PHP 5.5.0 final has been released!
Well done! Congratulations! On 20 Jun 2013 23:23, Julien Pauli jpa...@php.net wrote: Hello! The PHP Development Team would like to announce the immediate release of PHP 5.5.0. This release includes a large number of new features and bug fixes. A separate release announcement is also available. For changes in PHP 5.5.0 since PHP 5.4, please consult the PHP 5 ChangeLog. Release Announcement: http://www.php.net/release_5_5_0.php Downloads:http://www.php.net/downloads.php#v5.5 Changelog:http://www.php.net/ChangeLog-5.php#5.5.0 Thanks to all contributors that made this new version available. regards, David Soria Parra Julien Pauli
Re: [PHP-DEV] Disabling the GC during shutdown
Hi! Honestly, I am not sure. Every report that I've seen has it happening at shutdown. Could very well be a coincidence. Well, if we don't know why or if it's shutdown only, disabling on shutdown wouldn't do much good. I have a patch which prevents the segfault: https://github.com/ircmaxell/php-src/compare/invalidate_object_on_dtor However, that's not really fixing the situation either, as the zval is still getting nuked (but only partially). If there's a memory overwrite or use-after-free is going on, this patch is not a complete solution - it relies on the fact that bad data will be always out of range of good data. I see no way to ensure that - so if there's an overwrite that writes garbage inside the object there will be situations where the garbage looks exactly like a valid object ID and it will still crash, but it would be significantly harder to reproduce. So I think before patching it we need to get to the root cause and figure out why it happens and what causes it, instead of partially fixing the symptoms. And no, I'm withdrawing the original concept of disabling the GC during shutdown. The current patch I have works, but it's still just a bandaid on a gunshot wound, and I'm going to try to figure out what's actually overwriting the zval.. That'd be great, if you have any script that reproduces - always or at least frequently - the problem, please post it. -- 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: About to end 5.3
Thanks Johannes! This will be the longest running branch in PHP's history (spanning nearly 5 years now), not only PHP 5 (which is now going on almost a decade). Superb job and thanks to everyone else who contributed. Fair well 5.3... We'll miss you!
