# Pear fetch script problem on PHP 7.0 - Thread: https://externals.io/message/89293 - Original archive: https://news-web.php.net/php.internals/89293 - Started by Lior Kaplan on 2015-11-22T11:23:17+00:00 - Messages: 7 - 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 --- ## #89293 — Lior Kaplan — 2015-11-22T11:23:17+00:00 URL: https://externals.io/message/89293#89293 Hi, Trying to build PHP 7 RC7 on Darwin I get: [activating module `php7' in /usr/local/zend/apache2/conf/httpd.conf] Installing PHP CLI binary: /usr/local/zend/bin/ Installing PHP CLI man page: /usr/local/zend/share/man/man1/ Installing phpdbg binary: /usr/local/zend/bin/ Installing phpdbg man page: /usr/local/zend/share/man/man1/ Installing PHP CGI binary: /usr/local/zend/bin/ Installing PHP CGI man page: /usr/local/zend/share/man/man1/ Installing build environment: /usr/local/zend/lib/php/build/ Installing header files: /usr/local/zend/include/php/ Installing helper programs: /usr/local/zend/bin/ program: phpize program: php-config Installing man pages: /usr/local/zend/share/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/zend/share/pear/ Fatal error: Redefinition of parameter $argv in /php-7.0.0RC7/pear/fetch.php on line 3 make: *** [install-pear] Error 255 Has anyone encounter this from pear/fetch.php ? I could build PHP 5.6.15 in the same environment without a problem (and the file is the same in 5.6/7.0). Kaplan p.s. Most Linux environments have wget/curl so they are used before that script (part of the "make pear-install" target). --- ## #89296 — Andrea Faulds — 2015-11-22T20:51:59+00:00 URL: https://externals.io/message/89293#89296 · In reply to: #89293 Hi Lior, Lior Kaplan wrote: > Fatal error: Redefinition of parameter $argv in > /php-7.0.0RC7/pear/fetch.php on line 3 > make: *** [install-pear] Error 255 This is a strange and rather concerning error message. If I look at the source code of /pear/fetch.php in php-src, line three looks like this: function usage($argv) { $argv here is only specified once in the parameter list, yet it produces an error. Now, presumably this is some sort of conflict with the global variable $argv. But that's a global, not a superglobal, so it really shouldn't cause an error here. This looks like it might be a serious PHP 7 bug. And yet I can't reproduce it by running pear/fetch.php. Is something weird going on here? Thanks. -- Andrea Faulds http://ajf.me/ --- ## #89300 — Ferenc Kovacs — 2015-11-23T00:10:56+00:00 URL: https://externals.io/message/89293#89300 · In reply to: #89293 > Hi, > > Trying to build PHP 7 RC7 on Darwin I get: > > [activating module `php7' in /usr/local/zend/apache2/conf/httpd.conf] > Installing PHP CLI binary: /usr/local/zend/bin/ > Installing PHP CLI man page: /usr/local/zend/share/man/man1/ > Installing phpdbg binary: /usr/local/zend/bin/ > Installing phpdbg man page: /usr/local/zend/share/man/man1/ > Installing PHP CGI binary: /usr/local/zend/bin/ > Installing PHP CGI man page: /usr/local/zend/share/man/man1/ > Installing build environment: /usr/local/zend/lib/php/build/ > Installing header files: /usr/local/zend/include/php/ > Installing helper programs: /usr/local/zend/bin/ > program: phpize > program: php-config > Installing man pages: /usr/local/zend/share/man/man1/ > page: phpize.1 > page: php-config.1 > Installing PEAR environment: /usr/local/zend/share/pear/ > > Fatal error: Redefinition of parameter $argv in > /php-7.0.0RC7/pear/fetch.php on line 3 > make: *** [install-pear] Error 255 > > Has anyone encounter this from pear/fetch.php ? I could build PHP 5.6.15 in > the same environment without a problem (and the file is the same in > 5.6/7.0). > > Kaplan > > p.s. > Most Linux environments have wget/curl so they are used before that script > (part of the "make pear-install" target). > I couldn't reproduce the issue: Installing PEAR environment: /Users/tyrael/php-7.0.0RC7/lib/php/ Connected... Filesize: 3579275 Mime-type: text/plain; charset=UTF-8 [====================================================================================================>] 100% (3495/3495 kb) Done! -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #89321 — Lior Kaplan — 2015-11-23T09:57:56+00:00 URL: https://externals.io/message/89293#89321 · In reply to: #89296 Hi, Thanks Ferenc for checking. trying to debug this, I've added "echo var_dump($argv);" in the begining of the script, but now it segfault. before: sh-3.2# /php-7.0.0RC7/sapi/cli/php -n /php-7.0.0RC7/pear/fetch.php " http://5.77.39.20/install-pear-nozlib.phar" pear/install-pear-nozlib.phar Fatal error: Redefinition of parameter $argv in /php-7.0.0RC7/pear/fetch.php on line 3 sh-3.2# /php-7.0.0RC7/sapi/cli/php -n -m [PHP Modules] Core date dom filter hash iconv json libxml mysqlnd openssl pcre PDO pdo_mysql pdo_pgsql pdo_sqlite readline Reflection session SimpleXML SPL sqlite3 standard xml xmlreader xmlwriter zlib [Zend Modules] after: (gdb) r -n /php-7.0.0RC7/pear/fetch.php " http://5.77.39.20/install-pear-nozlib.phar" pear/install-pear-nozlib.phar Starting program: /php-7.0.0RC7/sapi/cli/php -n /php-7.0.0RC7/pear/fetch.php "http://5.77.39.20/install-pear-nozlib.phar" pear/install-pear-nozlib.phar Reading symbols for shared libraries ++++++................................................ done Reading symbols for shared libraries ........................ done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010 zend_try_compile_cv (result=0x7fff5fbfe440, ast=0x103e6f100) at zend_compile.c:2178 2178 if (zend_string_equals_literal(name, "this")) { (gdb) bt #0 zend_try_compile_cv (result=0x7fff5fbfe440, ast=0x103e6f100) at zend_compile.c:2178 #1 0x00000001002b7ff1 in zend_compile_simple_var [inlined] () at /php-7.0.0RC7/Zend/zend_compile.c:2226 #2 0x00000001002b7ff1 in zend_compile_var (result=0x7fff5fbfe440, ast=0x103e6f100, type=0) at zend_compile.c:7219 #3 0x00000001002bb46d in zend_compile_args (ast=0xfffffffffffff2f5, fbc=0x103e6f100) at zend_compile.c:2722 #4 0x00000001002b7e62 in zend_compile_call_common (result=0x7fff5fbfe648, args_ast=0xfffffffffffff2f5, fbc=0x10232e050) at zend_compile.c:2810 #5 0x00000001002ba8e5 in zend_compile_call (result=0x7fff5fbfe648, ast=0x103e6f100, type=65523712) at zend_compile.c:3245 #6 0x00000001002b7366 in zend_compile_expr (result=0x7fff5fbfe648, ast=0x103e6f100) at zend_compile.c:7111 #7 0x00000001002b428f in zend_compile_echo [inlined] () at /php-7.0.0RC7/Zend/zend_compile.c:3616 #8 0x00000001002b428f in zend_compile_stmt (ast=0x103e750d0) at zend_compile.c:7007 #9 0x00000001002b7990 in zend_compile_top_stmt (ast=0x103e750d0) at zend_compile.c:6966 #10 0x00000001002b797d in zend_compile_top_stmt (ast=0x103e750e0) at zend_compile.c:6961 #11 0x00000001002b797d in zend_compile_top_stmt (ast=0x103e770a8) at zend_compile.c:6961 #12 0x000000010029e6f2 in compile_file (file_handle=0x7fff5fbfe728, type=65523712) at zend_language_scanner.l:607 #13 0x00000001002cc4dc in zend_execute_scripts (type=8, retval=0x7fff5fbfe990, file_count=1606412688) at zend.c:1422 #14 0x000000010026a1a9 in php_execute_script (primary_file=0x7fff5fbff6d8) at main.c:2471 #15 0x000000010035dad4 in do_cli [inlined] () at /php-7.0.0RC7/sapi/cli/php_cli.c:974 #16 0x000000010035dad4 in main (argc=1606416352, argv=0x7fff5fbff7e0) at php_cli.c:1345 (again, works fine on Linux) Kaplan > Hi Lior, > > Lior Kaplan wrote: > > > […] > > This is a strange and rather concerning error message. If I look at the > source code of /pear/fetch.php in php-src, line three looks like this: > > function usage($argv) { > > $argv here is only specified once in the parameter list, yet it produces > an error. Now, presumably this is some sort of conflict with the global > variable $argv. But that's a global, not a superglobal, so it really > shouldn't cause an error here. > > This looks like it might be a serious PHP 7 bug. > > And yet I can't reproduce it by running pear/fetch.php. Is something weird > going on here? > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ --- ## #89872 — Matt Wilmas — 2015-12-22T17:36:00+00:00 URL: https://externals.io/message/89293#89872 · In reply to: #89321 Hi all, Lior, which compiler are you using? You can still reproduce the problem? Can you run it through Valgrind? I'm getting random crashes I can't figure out on 64-bit Linux after just making a very trivial change. :-/ The backtrace is the same up to compile_file() (although maybe that doesn't mean much? hmm). Dmitry, to reproduce, just add another GLOBAL REGISTER variable to zend_vm_execute, and then set it in execute_ex(). An empty file will crash it. It does NOT crash with --enable-debug, nor with certain combinations of optimization level and global register. %r12 with -O2 seems to consistently fail, but with -O3 it might be %r13, etc. Now, the question: Is that little change triggering a bug in GCC 4.8? Or is it somehow revealing a PHP problem?! Thanks, Matt ----- Original Message ----- From: "Lior Kaplan" Sent: Monday, November 23, 2015 > Hi, > > Thanks Ferenc for checking. > > trying to debug this, I've added "echo var_dump($argv);" in the begining > of > the script, but now it segfault. > > before: > sh-3.2# /php-7.0.0RC7/sapi/cli/php -n /php-7.0.0RC7/pear/fetch.php " > http://5.77.39.20/install-pear-nozlib.phar" pear/install-pear-nozlib.phar > > Fatal error: Redefinition of parameter $argv in > /php-7.0.0RC7/pear/fetch.php on line 3 > sh-3.2# /php-7.0.0RC7/sapi/cli/php -n -m > [PHP Modules] > Core > date > dom > filter > hash > iconv > json > libxml > mysqlnd > openssl > pcre > PDO > pdo_mysql > pdo_pgsql > pdo_sqlite > readline > Reflection > session > SimpleXML > SPL > sqlite3 > standard > xml > xmlreader > xmlwriter > zlib > > [Zend Modules] > > after: > > (gdb) r -n /php-7.0.0RC7/pear/fetch.php " > http://5.77.39.20/install-pear-nozlib.phar" pear/install-pear-nozlib.phar > Starting program: /php-7.0.0RC7/sapi/cli/php -n > /php-7.0.0RC7/pear/fetch.php "http://5.77.39.20/install-pear-nozlib.phar" > pear/install-pear-nozlib.phar > Reading symbols for shared libraries > ++++++................................................ done > Reading symbols for shared libraries ........................ done > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010 > zend_try_compile_cv (result=0x7fff5fbfe440, ast=0x103e6f100) at > zend_compile.c:2178 > 2178 if (zend_string_equals_literal(name, "this")) { > (gdb) bt > #0 zend_try_compile_cv (result=0x7fff5fbfe440, ast=0x103e6f100) at > zend_compile.c:2178 > #1 0x00000001002b7ff1 in zend_compile_simple_var [inlined] () at > /php-7.0.0RC7/Zend/zend_compile.c:2226 > #2 0x00000001002b7ff1 in zend_compile_var (result=0x7fff5fbfe440, > ast=0x103e6f100, type=0) at zend_compile.c:7219 > #3 0x00000001002bb46d in zend_compile_args (ast=0xfffffffffffff2f5, > fbc=0x103e6f100) at zend_compile.c:2722 > #4 0x00000001002b7e62 in zend_compile_call_common (result=0x7fff5fbfe648, > args_ast=0xfffffffffffff2f5, fbc=0x10232e050) at zend_compile.c:2810 > #5 0x00000001002ba8e5 in zend_compile_call (result=0x7fff5fbfe648, > ast=0x103e6f100, type=65523712) at zend_compile.c:3245 > #6 0x00000001002b7366 in zend_compile_expr (result=0x7fff5fbfe648, > ast=0x103e6f100) at zend_compile.c:7111 > #7 0x00000001002b428f in zend_compile_echo [inlined] () at > /php-7.0.0RC7/Zend/zend_compile.c:3616 > #8 0x00000001002b428f in zend_compile_stmt (ast=0x103e750d0) at > zend_compile.c:7007 > #9 0x00000001002b7990 in zend_compile_top_stmt (ast=0x103e750d0) at > zend_compile.c:6966 > #10 0x00000001002b797d in zend_compile_top_stmt (ast=0x103e750e0) at > zend_compile.c:6961 > #11 0x00000001002b797d in zend_compile_top_stmt (ast=0x103e770a8) at > zend_compile.c:6961 > #12 0x000000010029e6f2 in compile_file (file_handle=0x7fff5fbfe728, > type=65523712) at zend_language_scanner.l:607 > #13 0x00000001002cc4dc in zend_execute_scripts (type=8, > retval=0x7fff5fbfe990, file_count=1606412688) at zend.c:1422 > #14 0x000000010026a1a9 in php_execute_script (primary_file=0x7fff5fbff6d8) > at main.c:2471 > #15 0x000000010035dad4 in do_cli [inlined] () at > /php-7.0.0RC7/sapi/cli/php_cli.c:974 > #16 0x000000010035dad4 in main (argc=1606416352, argv=0x7fff5fbff7e0) at > php_cli.c:1345 > > (again, works fine on Linux) > > > > > Kaplan > > > > > > > […] --- ## #89873 — Dmitry Stogov — 2015-12-22T18:12:31+00:00 URL: https://externals.io/message/89293#89873 · In reply to: #89872 Hi Matt, On Tue, Dec 22, 2015 at 8:36 PM, Matt Wilmas wrote: > Hi all, > > Lior, which compiler are you using? You can still reproduce the problem? > Can you run it through Valgrind? > > I'm getting random crashes I can't figure out on 64-bit Linux after just > making a very trivial change. :-/ The backtrace is the same up to > compile_file() (although maybe that doesn't mean much? hmm). > > Dmitry, to reproduce, just add another GLOBAL REGISTER variable to > zend_vm_execute, and then set it in execute_ex(). An empty file will crash > it. It does NOT crash with --enable-debug, nor with certain combinations > of optimization level and global register. > Using another global register is not a trivial change. > %r12 with -O2 seems to consistently fail, but with -O3 it might be %r13, > etc. > In general both should work fine, but it seems like this feature is not well debugged in GCC and may lead to miscompilation. > Now, the question: Is that little change triggering a bug in GCC 4.8? Or > is it somehow revealing a PHP problem?! > It may be a GCC bug, as well as a bug in your code... may be you need to save/restore it manually in execute_ex()? Thanks. Dmitry. > > > Thanks, > Matt > > > ----- Original Message ----- > From: "Lior Kaplan" > Sent: Monday, November 23, 2015 > > Hi, > > […] --- ## #89874 — Matt Wilmas — 2015-12-22T20:00:44+00:00 URL: https://externals.io/message/89293#89874 · In reply to: #89873 Hi Dmitry! ----- Original Message ----- From: "Dmitry Stogov" Sent: Tuesday, December 22, 2015 > Hi Matt, > > On Tue, Dec 22, 2015 at 8:36 PM, Matt Wilmas > wrote: > > > […] > > Using another global register is not a trivial change. Well, I meant relatively since a couple are already used. ;-) And thought GCC managed it all... (wrong). > > […] > > In general both should work fine, but it seems like this feature is not > well debugged in GCC and may lead to miscompilation. Right, I remember you requiring min. 4.8 back in the spring after issues with earlier versions. And now I wondered if something was still unstable and only working by chance. > > […] > > It may be a GCC bug, as well as a bug in your code... > may be you need to save/restore it manually in execute_ex()? Argh!! Do I feel dumb. :-( And that's even what's happening right there with the others. (I was thinking of those as executor-specific save/restore, rather than the registers themselves.) And seems I had it reversed thinking the caller would save its own first, which of course is wrong for CALLEE-saved regs. Looks like any combo is working fine now. I had the changes as a whole all working quickly (will reply to your previous subject soon) by luck. I tried everything else after crashes started... Who knows how long it would've taken if not for your reminder! :-) > Thanks. Dmitry. Thanks again, and sorry for the noise. - Matt