Bug #76466 [Ana]: Loop variable confusion
| From: | nikic@php.net | Date: | Fri, 15 Jun 2018 16:53:45 +0000 |
| Subject: | Bug #76466 [Ana]: Loop variable confusion | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-215748@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=76466&edit=1
ID: 76466
Updated by: nikic@php.net
Reported by: cmb@php.net
Summary: Loop variable confusion
Status: Analyzed
Type: Bug
Package: opcache
Operating System: Linux
PHP Version: 7.3.0alpha1
Assigned To: laruence
Block user comment: N
Private report: N
New Comment:
@dmitry: It should not be necessary to manually BOT out the chain. If you only set the current
result to BOT, the value will be propagated.
Of course returning BOT here will prevent us from catching certain patterns, though probably they
aren't particularly important to us.
Previous Comments:
------------------------------------------------------------------------
[2018-06-15 09:59:31] dmitry@php.net
@laruence @nikic
I propose another approach - make BOT all the chain of ADD_ARRAY_ELEMENT opcodes, when some variable
changes.
Please review https://gist.github.com/dstogov/142223b0c42c49a523f72a814db8b4f0
------------------------------------------------------------------------
[2018-06-14 14:47:08] laruence@php.net
@nikic probably you saw the old patchï¼ the result parts are already changed :)
about the array size limit, yeah, it's good idea... as after this change the array numbers will
increased visibly.
I've asked dmitry to also have a look.. let's see what's his opinion .
------------------------------------------------------------------------
[2018-06-14 09:46:55] nikic@php.net
@laruence: Yes, this is clearly wrong. Without the partial array propagation this would still be
fine if we made sure to propagate a BOT op1/op2 before the check (which we didn't do
either...), as we know that these are the only possible lowerings and both result in a BOT. However,
with partial arrays this is no longer possible, so I'd say we should remove this (you'll
also have to modify the if (result) code below) and instead add a check for the array size and
return BOT if the array is larger than say 16 elements, to avoid quadratic blowup.
------------------------------------------------------------------------
[2018-06-14 09:26:54] laruence@php.net
the problem is that we may visit one instruction multiply times, depends on new infos comes... let
me try to explain:
let say we have two ops
#1 INIT_ARRAY
#2 ADD_ARRAY_ELEMENT
when we first visit INIT_ARRAY, we have op1 is an const value, then we set INIT_ARRAYâs
result as a const array.
then we visist #2, we get the result value from #1, and set the #1 result to NULL, then make #2
result a const array.
but later, INIT_ARRAY op1âs value become BOT⦠and #1 is added into work instr againâ¦
but this time, we visist #1, we get INIT_ARRAY->Result.def is IS_NULL, then we simply return,
then we leave #2âs result as an incorrect value typeâ¦. (it should be BOT, but itâs
array)
fix could be something like https://gist.github.com/laruence/4068c564e38e8e0f84148cc1b3f977cf
------------------------------------------------------------------------
[2018-06-13 13:17:41] cmb@php.net
Looks like the SCCP is too aggressive as of commit ce3dbb5[1].
For what it's worth, removing the if statement from the test
script gives expected results.
[1] <https://github.com/php/php-src/commit/ce3dbb53a7dcef314bba1d355f049ddb2252fad1>
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=76466
--
Edit this bug report at https://bugs.php.net/bug.php?id=76466&edit=1