Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89873
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4342ECED904143CD9AC7AA35F2F1481B@pc1>
References: <CAPJnDK0Q9Z3YUKeK28M_cFpngSWEgEb0-hrBhdSv2rkgdT06cg@mail.gmail.com>
	<8E.46.23339.4FA22565@pb1.pair.com>
	<CAPJnDK1kPaDWieqBbW4ab4-TatZZ3DtpkRQHrU5Nhdmf-sKvjw@mail.gmail.com>
	<4342ECED904143CD9AC7AA35F2F1481B@pc1>
Date: Tue, 22 Dec 2015 21:12:31 +0300
Message-ID: <CA+9eiLsctMxLEeW716Njh3sLGpLKY0hcxvj0jZCZo4JBLCcMxA@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>
Cc: PHP internals list <internals@lists.php.net>, Lior Kaplan <lior.k@zend.com>, Andrea Faulds <ajf@ajf.me>
Content-Type: multipart/alternative; boundary=089e0122f6e0931ba20527808c4e
Subject: Re: Mysterious crashes (WAS: Re: Pear fetch script problem on PHP 7.0)
From: dmitry@zend.com (Dmitry Stogov)

--089e0122f6e0931ba20527808c4e
Content-Type: text/plain; charset=UTF-8

Hi Matt,

On Tue, Dec 22, 2015 at 8:36 PM, Matt Wilmas <php_lists@realplain.com>
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,
>>
>> 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
>>
>>
>>
>> On Sun, Nov 22, 2015 at 10:51 PM, Andrea Faulds <ajf@ajf.me> wrote:
>>
>> 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/
>>>
>>
>

--089e0122f6e0931ba20527808c4e--