# PHP7 Homework for everyone reading this list - Thread: https://externals.io/message/80978 - Original archive: https://news-web.php.net/php.internals/80978 - Started by Rasmus Lerdorf on 2015-01-22T17:05:28+00:00 - Messages: 42 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/80978.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #80978 — Rasmus Lerdorf — 2015-01-22T17:05:28+00:00 URL: https://externals.io/message/80978#80978 By installing a couple of apps (Wordpress-4.1, Drupal8 and Moodle - there are still some issues in Moodle I haven't figured out yet) on a box we've tracked down some bugs over the last couple of days. It would be really useful if we got more eyes on this. Install php7, then install any random app and see how it goes. Sometimes it is useful to flip back and forth between 5.6 and 7 to check if a problem is php7-specific, so I have php56-fpm sitting alongside php7-fpm and it is trivial to switch back and forth. Hopefully everyone here knows how to compile from git and get things up and running. But, if someone is good with building sharable container images of some kind, that might be a nice contribution as well. An image with clear instructions telling people to drop their app into /var/www/whatever and add the appropriate nginx/apache vhost block and they are set. -Rasmus --- ## #80979 — Sebastian Bergmann — 2015-01-22T17:36:42+00:00 URL: https://externals.io/message/80978#80979 · In reply to: #80978 Am 22.01.2015 um 18:05 schrieb Rasmus Lerdorf: > It would be really useful if we got more eyes on this. Install php7, > then install any random app and see how it goes. It's even easier to check whether a component or framework has issues with PHP 7: simply run the respective test suite with PHP 7. With the exception of one test case, the test suite for PHPUnit itself runs without a problem on PHP 7. The one test that fails is related to the textual representation of SplObjectStorage objects: Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ - ) +- 'inf' => null +- ) +- '000000006a6ff9c8000000006911d926' => Array &1 ( +SplObjectStorage Object &000000006a6ff9ce000000006910251e ( + '000000006a6ff9c8000000006911d926' => Array &0 ( -+ 'obj' => stdClass Object &000000006a6ff9c8000000006911d926 () + 'obj' => stdClass Object &000000006a6ff9c8000000006911d926 () 'inf' => null ) -- '000000006a6ff9c8000000006911d926' => Array &0 ) ' Hopefully I'll have the time soon to investigate this. It would be great if Travis CI would offer PHP 7 nightly / weekly builds to test against. The we could ask the projects that run their tests on Travis CI to enable PHP 7 for their builds. --- ## #80980 — Julien Pauli — 2015-01-22T17:39:37+00:00 URL: https://externals.io/message/80978#80980 · In reply to: #80979 On Thu, Jan 22, 2015 at 6:36 PM, Sebastian Bergmann wrote: > Am 22.01.2015 um 18:05 schrieb Rasmus Lerdorf: > > […] > > It's even easier to check whether a component or framework has issues > with PHP 7: simply run the respective test suite with PHP 7. > > With the exception of one test case, the test suite for PHPUnit > itself runs without a problem on PHP 7. The one test that fails is > related to the textual representation of SplObjectStorage objects: > > Failed asserting that two strings are equal. > --- Expected > +++ Actual > @@ @@ > - ) > +- 'inf' => null > +- ) > +- '000000006a6ff9c8000000006911d926' => Array &1 ( > +SplObjectStorage Object &000000006a6ff9ce000000006910251e ( > + '000000006a6ff9c8000000006911d926' => Array &0 ( > -+ 'obj' => stdClass Object &000000006a6ff9c8000000006911d926 () > + 'obj' => stdClass Object &000000006a6ff9c8000000006911d926 () > 'inf' => null > ) > -- '000000006a6ff9c8000000006911d926' => Array &0 > ) > ' > > Hopefully I'll have the time soon to investigate this. > > It would be great if Travis CI would offer PHP 7 nightly / weekly > builds to test against. The we could ask the projects that run their > tests on Travis CI to enable PHP 7 for their builds. Hello, I used to run Symfony2 and Doctrine2 test suite on PHP7. I will push such tests in the next time, and run them when I run PHP 5.x new release against those tests Julien.P --- ## #80982 — Matteo Beccati — 2015-01-22T18:04:41+00:00 URL: https://externals.io/message/80978#80982 · In reply to: #80979 Hi, > -+ 'obj' => stdClass Object &000000006a6ff9c8000000006911d926 () > + 'obj' => stdClass Object &000000006a6ff9c8000000006911d926 () > 'inf' => null > ) > -- '000000006a6ff9c8000000006911d926' => Array &0 > ) > ' > > Hopefully I'll have the time soon to investigate this. > > It would be great if Travis CI would offer PHP 7 nightly / weekly > builds to test against. The we could ask the projects that run their > tests on Travis CI to enable PHP 7 for their builds. FWIW, I've been doing this since quite a long time already for a few selected projects (including PHPUnit) on: https://revive.beccati.com/bamboo/ I've been monitoring the project builds and reporting failures on #php.pecl. Until now, this has proved to be very useful. I had to quarantine a couple of tests in Doctrine and PHPUnit as they both depend on the re-usage of the hashes returned by `spl_object_hash()`, which shouldn't actually be depended upon (am I right dmitry?). Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #80983 — Levi Morrison — 2015-01-22T18:32:19+00:00 URL: https://externals.io/message/80978#80983 · In reply to: #80982 > I had to quarantine a couple of tests in Doctrine and PHPUnit as they both > depend on the re-usage of the hashes returned by `spl_object_hash()`, which > shouldn't actually be depended upon (am I right dmitry?). I'm not Dmitry, but I am fairly certain you should not rely on hashes being reused. --- ## #80984 — Matteo Beccati — 2015-01-22T18:39:28+00:00 URL: https://externals.io/message/80978#80984 · In reply to: #80983 > > […] > > I'm not Dmitry, but I am fairly certain you should not rely on hashes > being reused. I was quoting a quick discussion we had, that's why I mentioned him ;) To make my stament clearer, I meant "spl_object_hash re-using the hash of an object that has been unset and garbage collected". TBH I don't recall what the PHPUnit test does, but I'm fairly sure that the Doctrine2 tests uses such test to verify that there are no "leaks" using a certain recommended pattern for batch operations (or something along the lines). Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #80986 — Dmitry Stogov — 2015-01-22T19:34:13+00:00 URL: https://externals.io/message/80978#80986 · In reply to: #80984 Hi, Our attempt to run Drupal-8 today, disclosed at least 3 new problems. 2 of them must be already fixed, but I know we must have a lot of other problems uncovered by our test suite. Every new tested app my trigger something new. The more attention we draw now the better quality we will provide. Instead of using FPM, especially for testing, it may make sense to run single FastCGI process $ sapi/cgi/php-cgi -b DEBUG build will report memory leaks to analyze memory corryption and leaks, it's also possible to run php under valgrind $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi -b No any special web server configuration required, just configure it for FastCGI server on the . Then you may run FPM or FastCGI SAPI or even HHVM on the same without web server restart. Thanks. Dmitry. > > > > […] > > I was quoting a quick discussion we had, that's why I mentioned him ;) > > To make my stament clearer, I meant "spl_object_hash re-using the hash of > an object that has been unset and garbage collected". > > TBH I don't recall what the PHPUnit test does, but I'm fairly sure that > the Doctrine2 tests uses such test to verify that there are no "leaks" > using a certain recommended pattern for batch operations (or something > along the lines). > > > > Cheers > -- > Matteo Beccati > > Development & Consulting - http://www.beccati.com/ --- ## #80992 — Lester Caine — 2015-01-22T21:07:36+00:00 URL: https://externals.io/message/80978#80992 · In reply to: #80978 > Install php7, then install any random app and see how it goes. When I can actually run my infrastructure on PHP7 then I could at least see if there is a performance improvement. Although I think only interbase is left on the unavailable list. imagick is now available? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #80993 — Florian Anderiasch — 2015-01-22T21:23:32+00:00 URL: https://externals.io/message/80978#80993 · In reply to: #80978 > By installing a couple of apps (Wordpress-4.1, Drupal8 and Moodle - > there are still some issues in Moodle I haven't figured out yet) on a > box we've tracked down some bugs over the last couple of days. It would > be really useful if we got more eyes on this. Install php7, then install > any random app and see how it goes. Sometimes it is useful to flip back > and forth between 5.6 and 7 to check if a problem is php7-specific, so I > have php56-fpm sitting alongside php7-fpm and it is trivial to switch > back and forth. We're obviously not Wordpress-level famous but phpMyFAQ has a demo install with master (not updated nightly, but regularly) at http://richmond.demo.phpmyfaq.de/ (along with 5.4, 5.5, 5.6 and HHVM) and our latest release - everything running smooth so far. Maybe something like https://python3wos.appspot.com/ could make sense for PHP apps and/or extensions? Greetings, Florian --- ## #80994 — Jan Ehrhardt — 2015-01-22T21:43:30+00:00 URL: https://externals.io/message/80978#80994 · In reply to: #80978 Rasmus Lerdorf in php.internals (Thu, 22 Jan 2015 09:05:28 -0800): >Hopefully everyone here knows how to compile from git and get things up >and running. I would love to test a Windows build with all kinds of extensions if there was a consistent way to find out which branch I'd have to checkout. For http v2, propro and raphf that is the 'phpng' branch, but I have no idea what choices other extension maintainers have made. Jan --- ## #80995 — Benjamin Eberlei — 2015-01-22T22:02:56+00:00 URL: https://externals.io/message/80978#80995 · In reply to: #80983 > > […] > both > > […] > > I'm not Dmitry, but I am fairly certain you should not rely on hashes > being reused. > The test in Doctrine is not about hashes being reused, but about testing hashes are not reused. It might be written in a way where a change of the hash is not portable though. --- ## #80997 — Dan Ackroyd — 2015-01-22T22:30:27+00:00 URL: https://externals.io/message/80978#80997 · In reply to: #80992 > imagick is now available? Not yet. I'll try to finish it off before the end of the weekend. Most of the work was done earlier, but I need to add the changes for the Native TLS. btw this request to update the PHPNG upgrading guide is still open: > Thanks. I think the TSRM changes need to be added, which could be copied from: > https://github.com/php/php-src/commit/dec8eb431adee340fb8dfb9ff33ed29d3279c35f > Providing a link to a commit that implemented the TSRM changes for an > extension, so that people could see the actual changes needed, would > be awesome. cheers Dan --- ## #81006 — Rasmus Lerdorf — 2015-01-23T00:19:50+00:00 URL: https://externals.io/message/80978#81006 · In reply to: #80997 > > > […] > > Not yet. I'll try to finish it off before the end of the weekend. Most > of the work was done earlier, but I need to add the changes for the > Native TLS. > > btw this request to update the PHPNG upgrading guide is still open: > > > […] For most extensions that just do something simple like imagick does: #ifdef ZTS # define IMAGICK_G(v) TSRMG(imagick_globals_id, zend_imagick_globals *, v) #else # define IMAGICK_G(v) (imagick_globals.v) #endif There is absolutely nothing to do. You can, just for your own amusement and because it makes the code look prettier, go through and remove all instances of TSRMLS_* macros in all your C files. But it isn't critical since they are just defined to nothing in PHP7. Just leave that TSRMG define in your .h file and it will do the right thing. -Rasmus --- ## #81017 — Juan Basso — 2015-01-23T04:45:15+00:00 URL: https://externals.io/message/80978#81017 · In reply to: #81006 Trying to run phpunit on the latest CakePHP 3 gives a lot of errors of this type (not on every test case): php: /.../php-src/Zend/zend_gc.c:144: gc_possible_root: Assertion `((zend_refcounted*)(ref))->u.v.type == 7 || ((zend_refcounted*)(ref))->u.v.type == 8' failed. This errors happens after the test is completed and all output from PHPUnit is done. I am using Ubuntu 12.04 with and the last commit of my php is b8e262901e56a4d9a6664d348c9878246579239e (Thu Jan 22 14:04:49 2015 -0800). This is the gdb backtrace: (gdb) bt #0 0x00007ffff61840d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff618783b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff617cd9e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff617ce42 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x000000000090ed19 in gc_possible_root (ref=0x7ffff4038820) at /.../php-src/Zend/zend_gc.c:144 #5 0x00000000008f1b25 in gc_check_possible_root (z=0x7ffff40302e0) at /.../php-src/Zend/zend_gc.h:145 #6 0x00000000008f1b83 in i_zval_ptr_dtor (zval_ptr=0x7ffff40302e0, __zend_filename=0xe493f0 "/.../php-src/Zend/zend_hash.c", __zend_lineno=929) at /.../php-src/Zend/zend_variables.h:54 #7 0x00000000008f4824 in zend_array_destroy (ht=0x7ffff40391e8) at /.../php-src/Zend/zend_hash.c:929 #8 0x00000000008de252 in _zval_dtor_func_for_ptr (p=0x7ffff40391e0, __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", __zend_lineno=158) at /.../php-src/Zend/zend_variables.c:105 #9 0x00000000008c76d4 in i_zval_ptr_dtor (zval_ptr=0x7ffff43e3130, __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", __zend_lineno=158) at /.../php-src/Zend/zend_variables.h:52 #10 0x00000000008c8b43 in _zval_ptr_dtor (zval_ptr=0x7ffff43e3130, __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", __zend_lineno=158) at /.../php-src/Zend/zend_execute_API.c:483 #11 0x00000000008cdbce in zend_cleanup_user_class_data (ce=0x7ffff400e918) at /.../php-src/Zend/zend_opcode.c:158 #12 0x00000000008c84b2 in shutdown_executor () at /.../php-src/Zend/zend_execute_API.c:318 #13 0x00000000008e08ce in zend_deactivate () at /.../php-src/Zend/zend.c:886 #14 0x0000000000851d09 in php_request_shutdown (dummy=0x0) at /.../php-src/main/main.c:1856 #15 0x00000000009861e2 in do_cli (argc=3, argv=0x11b1990) at /.../php-src/sapi/cli/php_cli.c:1159 #16 0x000000000098696a in main (argc=3, argv=0x11b1990) at /.../php-src/sapi/cli/php_cli.c:1361 Any idea? I am trying to isolate the problem, but may take a while. > > > […] > copied from: > > […] > https://github.com/php/php-src/commit/dec8eb431adee340fb8dfb9ff33ed29d3279c35f > > […] > > For most extensions that just do something simple like imagick does: > > #ifdef ZTS > # define IMAGICK_G(v) TSRMG(imagick_globals_id, zend_imagick_globals *, v) > #else > # define IMAGICK_G(v) (imagick_globals.v) > #endif > > There is absolutely nothing to do. You can, just for your own amusement > and because it makes the code look prettier, go through and remove all > instances of TSRMLS_* macros in all your C files. But it isn't critical > since they are just defined to nothing in PHP7. Just leave that TSRMG > define in your .h file and it will do the right thing. > > -Rasmus --- ## #81019 — Juan Basso — 2015-01-23T05:17:33+00:00 URL: https://externals.io/message/80978#81019 · In reply to: #81017 I could isolate the problem. Here is a script to reproduce: https://gist.github.com/jrbasso/031fffc8f5eeaf872d4e The issue seems to be related when a new instance is loaded and then get_class_vars is called for the class holding the instance. Removing any of the lines from the static method avoids the error. Should I open an issue on bugs.php.net? > Trying to run phpunit on the latest CakePHP 3 gives a lot of errors of > this type (not on every test case): > > php: /.../php-src/Zend/zend_gc.c:144: gc_possible_root: Assertion > `((zend_refcounted*)(ref))->u.v.type == 7 || > ((zend_refcounted*)(ref))->u.v.type == 8' failed. > > This errors happens after the test is completed and all output from > PHPUnit is done. > I am using Ubuntu 12.04 with and the last commit of my php > is b8e262901e56a4d9a6664d348c9878246579239e (Thu Jan 22 14:04:49 2015 > -0800). > > This is the gdb backtrace: > > (gdb) bt > #0 0x00007ffff61840d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007ffff618783b in abort () from /lib/x86_64-linux-gnu/libc.so.6 > #2 0x00007ffff617cd9e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #3 0x00007ffff617ce42 in __assert_fail () from > /lib/x86_64-linux-gnu/libc.so.6 > #4 0x000000000090ed19 in gc_possible_root (ref=0x7ffff4038820) at > /.../php-src/Zend/zend_gc.c:144 > #5 0x00000000008f1b25 in gc_check_possible_root (z=0x7ffff40302e0) at > /.../php-src/Zend/zend_gc.h:145 > #6 0x00000000008f1b83 in i_zval_ptr_dtor (zval_ptr=0x7ffff40302e0, > __zend_filename=0xe493f0 "/.../php-src/Zend/zend_hash.c", > __zend_lineno=929) at /.../php-src/Zend/zend_variables.h:54 > #7 0x00000000008f4824 in zend_array_destroy (ht=0x7ffff40391e8) at > /.../php-src/Zend/zend_hash.c:929 > #8 0x00000000008de252 in _zval_dtor_func_for_ptr (p=0x7ffff40391e0, > __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", > __zend_lineno=158) at /.../php-src/Zend/zend_variables.c:105 > #9 0x00000000008c76d4 in i_zval_ptr_dtor (zval_ptr=0x7ffff43e3130, > __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", > __zend_lineno=158) at /.../php-src/Zend/zend_variables.h:52 > #10 0x00000000008c8b43 in _zval_ptr_dtor (zval_ptr=0x7ffff43e3130, > __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", > __zend_lineno=158) at /.../php-src/Zend/zend_execute_API.c:483 > #11 0x00000000008cdbce in zend_cleanup_user_class_data (ce=0x7ffff400e918) > at /.../php-src/Zend/zend_opcode.c:158 > #12 0x00000000008c84b2 in shutdown_executor () at > /.../php-src/Zend/zend_execute_API.c:318 > #13 0x00000000008e08ce in zend_deactivate () at > /.../php-src/Zend/zend.c:886 > #14 0x0000000000851d09 in php_request_shutdown (dummy=0x0) at > /.../php-src/main/main.c:1856 > #15 0x00000000009861e2 in do_cli (argc=3, argv=0x11b1990) at > /.../php-src/sapi/cli/php_cli.c:1159 > #16 0x000000000098696a in main (argc=3, argv=0x11b1990) at > /.../php-src/sapi/cli/php_cli.c:1361 > > > Any idea? I am trying to isolate the problem, but may take a while. > > On Thu, Jan 22, 2015 at 7:19 PM, Rasmus Lerdorf > wrote: > > > […] --- ## #81020 — Pierre Joye — 2015-01-23T05:23:55+00:00 URL: https://externals.io/message/80978#81020 · In reply to: #81019 > > I could isolate the problem. Here is a script to reproduce: > https://gist.github.com/jrbasso/031fffc8f5eeaf872d4e > > The issue seems to be related when a new instance is loaded and then > get_class_vars is called for the class holding the instance. Removing any > of the lines from the static method avoids the error. Nice work! Thanks :) > Should I open an issue on bugs.php.net? Yes, please :) --- ## #81021 — Xinchen Hui — 2015-01-23T05:30:54+00:00 URL: https://externals.io/message/80978#81021 · In reply to: #81020 Hey: > > > […] > > Nice work! Thanks :) > > > […] > > Yes, please :) I'v got a fix. thanks for the reporting :) thanks -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #81022 — Xinchen Hui — 2015-01-23T05:50:19+00:00 URL: https://externals.io/message/80978#81022 · In reply to: #81019 Hey: > I could isolate the problem. Here is a script to reproduce: > https://gist.github.com/jrbasso/031fffc8f5eeaf872d4e > > The issue seems to be related when a new instance is loaded and then > get_class_vars is called for the class holding the instance. Removing any > of the lines from the static method avoids the error. > > Should I open an issue on bugs.php.net? could you please try with the master again? thanks > > > > > […] -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #81023 — Juan Basso — 2015-01-23T05:56:49+00:00 URL: https://externals.io/message/80978#81023 · In reply to: #81022 Yes, just tested after your change and it solved the problem. Thanks for the quick fix. > Hey: > > > > > […] > could you please try with the master again? > > thanks > > […] > (ce=0x7ffff400e918) > > […] > wrote: > > […] > Most > > […] > https://github.com/php/php-src/commit/dec8eb431adee340fb8dfb9ff33ed29d3279c35f > > […] > an > > […] > *, v) > > […] > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ --- ## #81041 — Dmitry Stogov — 2015-01-23T13:54:45+00:00 URL: https://externals.io/message/80978#81041 · In reply to: #80994 "master" branch. > Rasmus Lerdorf in php.internals (Thu, 22 Jan 2015 09:05:28 -0800): > > […] > > I would love to test a Windows build with all kinds of extensions if > there was a consistent way to find out which branch I'd have to > checkout. For http v2, propro and raphf that is the 'phpng' branch, but > I have no idea what choices other extension maintainers have made. > > Jan --- ## #81042 — Dmitry Stogov — 2015-01-23T13:57:39+00:00 URL: https://externals.io/message/80978#81042 · In reply to: #81017 Thanks. This problem was introduced yesterday and must be already fixed. Dmitry. > Trying to run phpunit on the latest CakePHP 3 gives a lot of errors of this > type (not on every test case): > > php: /.../php-src/Zend/zend_gc.c:144: gc_possible_root: Assertion > `((zend_refcounted*)(ref))->u.v.type == 7 || > ((zend_refcounted*)(ref))->u.v.type == 8' failed. > > This errors happens after the test is completed and all output from PHPUnit > is done. > I am using Ubuntu 12.04 with and the last commit of my php > is b8e262901e56a4d9a6664d348c9878246579239e (Thu Jan 22 14:04:49 2015 > -0800). > > This is the gdb backtrace: > > (gdb) bt > #0 0x00007ffff61840d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007ffff618783b in abort () from /lib/x86_64-linux-gnu/libc.so.6 > #2 0x00007ffff617cd9e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #3 0x00007ffff617ce42 in __assert_fail () from > /lib/x86_64-linux-gnu/libc.so.6 > #4 0x000000000090ed19 in gc_possible_root (ref=0x7ffff4038820) at > /.../php-src/Zend/zend_gc.c:144 > #5 0x00000000008f1b25 in gc_check_possible_root (z=0x7ffff40302e0) at > /.../php-src/Zend/zend_gc.h:145 > #6 0x00000000008f1b83 in i_zval_ptr_dtor (zval_ptr=0x7ffff40302e0, > __zend_filename=0xe493f0 "/.../php-src/Zend/zend_hash.c", > __zend_lineno=929) at /.../php-src/Zend/zend_variables.h:54 > #7 0x00000000008f4824 in zend_array_destroy (ht=0x7ffff40391e8) at > /.../php-src/Zend/zend_hash.c:929 > #8 0x00000000008de252 in _zval_dtor_func_for_ptr (p=0x7ffff40391e0, > __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", > __zend_lineno=158) at /.../php-src/Zend/zend_variables.c:105 > #9 0x00000000008c76d4 in i_zval_ptr_dtor (zval_ptr=0x7ffff43e3130, > __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", > __zend_lineno=158) at /.../php-src/Zend/zend_variables.h:52 > #10 0x00000000008c8b43 in _zval_ptr_dtor (zval_ptr=0x7ffff43e3130, > __zend_filename=0xe46470 "/.../php-src/Zend/zend_opcode.c", > __zend_lineno=158) at /.../php-src/Zend/zend_execute_API.c:483 > #11 0x00000000008cdbce in zend_cleanup_user_class_data (ce=0x7ffff400e918) > at /.../php-src/Zend/zend_opcode.c:158 > #12 0x00000000008c84b2 in shutdown_executor () at > /.../php-src/Zend/zend_execute_API.c:318 > #13 0x00000000008e08ce in zend_deactivate () at > /.../php-src/Zend/zend.c:886 > #14 0x0000000000851d09 in php_request_shutdown (dummy=0x0) at > /.../php-src/main/main.c:1856 > #15 0x00000000009861e2 in do_cli (argc=3, argv=0x11b1990) at > /.../php-src/sapi/cli/php_cli.c:1159 > #16 0x000000000098696a in main (argc=3, argv=0x11b1990) at > /.../php-src/sapi/cli/php_cli.c:1361 > > > Any idea? I am trying to isolate the problem, but may take a while. > > On Thu, Jan 22, 2015 at 7:19 PM, Rasmus Lerdorf > wrote: > > > […] > https://github.com/php/php-src/commit/dec8eb431adee340fb8dfb9ff33ed29d3279c35f > > […] > v) > > […] --- ## #81050 — Jan Ehrhardt — 2015-01-23T21:18:50+00:00 URL: https://externals.io/message/80978#81050 · In reply to: #81041 Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >"master" branch. propro, raphf and pecl_http do not compile with the master branch. You'll have to checkout the phpng branch. These extensions did compile and load: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm Build: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip Maybe there are other PECL extension that have PHP7 branches, unknown to you and me. Jan --- ## #81051 — Jan Ehrhardt — 2015-01-23T21:24:56+00:00 URL: https://externals.io/message/80978#81051 · In reply to: #80992 Lester Caine in php.internals (Thu, 22 Jan 2015 21:07:36 +0000): > > > […] > >When I can actually run my infrastructure on PHP7 then I could at least >see if there is a performance improvement. Although I think only >interbase is left on the unavailable list. imagick is now available? Interbase builds and loads under Windows with VC11 x86. If it works I do not test: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip The configure line is misleading. For instance OCI does not build yet. Just look at the other output of `phpinfo()`. Jan --- ## #81053 — Jan Ehrhardt — 2015-01-23T22:01:59+00:00 URL: https://externals.io/message/80978#81053 · In reply to: #81050 Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): >Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): > > […] > >propro, raphf and pecl_http do not compile with the master branch. >You'll have to checkout the phpng branch. These extensions did compile >and load: >https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm > >Build: >https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip The TS build is very much alike: https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip What you cannot see in `phpinfo()` is that php7apache2_4.dll and even php7apache2_2.dll also compile fine. >Maybe there are other PECL extension that have PHP7 branches, unknown to >you and me. Jan --- ## #81068 — Juan Basso — 2015-01-24T04:54:20+00:00 URL: https://externals.io/message/80978#81068 · In reply to: #81053 I found another segment fault on PHP 7 during CakePHP 3 tests. I reported the issue on https://bugs.php.net/bug.php?id=68896 > Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): > > […] > > The TS build is very much alike: > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip > > What you cannot see in `phpinfo()` is that php7apache2_4.dll and even > php7apache2_2.dll also compile fine. > > > […] > > Jan --- Next page: https://externals.io/message/80978.md?page=2