php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #75405 Redundant ext infos after optimizing
Submitted: 2017-10-19 04:28 UTC Modified: 2017-11-21 13:10 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: laruence@php.net Assigned: laruence (profile)
Status: Assigned Package: *General Issues
PHP Version: 7.2.0RC4 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: laruence@php.net
New email:
PHP Version: OS:

 

 [2017-10-19 04:28 UTC] laruence@php.net 
Description:
------------
There are redundant ZEND_EXT_* oplines remained after optimized, this will make profiler/debugger confused..


Test script:
---------------
<?php
function foo(string $s1, string $s2) {
    $x = ($s1 . $s2);
    $x = 0;
    return $x;
}
?>

runwith  sapi/phpdbg/phpdbg  -e -p*  /tmp/1.php

Expected result:
----------------
function name: foo
L2-6 foo() /tmp/1.php - 0x7f54cbdde2d0 + 5 ops
 L2    #0     EXT_NOP
 L2    #1     RECV                    1                                         $s1
 L2    #2     RECV                    2                                         $s2
 L3    #3     EXT_STMT
 L5    #4     RETURN                  0
[Script ended normally]

Actual result:
--------------
function name: foo
L2-6 foo() /tmp/1.php - 0x7f79e13de2d0 + 7 ops
 L2    #0     EXT_NOP
 L2    #1     RECV                    1                                         $s1
 L2    #2     RECV                    2                                         $s2
 L3    #3     EXT_STMT
 L4    #4     EXT_STMT
 L5    #5     EXT_STMT
 L5    #6     RETURN                  0
[Script ended normally]

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-10-19 04:40 UTC] laruence@php.net
-Assigned To: +Assigned To: laruence
 [2017-10-19 09:18 UTC] derick@php.net 
I would argue that the expected result should be this instead:

Expected result:
----------------
function name: foo
L2-6 foo() /tmp/1.php - 0x7f54cbdde2d0 + 5 ops
 L2    #0     EXT_NOP
 L2    #1     RECV                    1                                         $s1
 L2    #2     RECV                    2                                         $s2
 L5    #3     EXT_STMT
 L5    #4     RETURN                  0
[Script ended normally]

i.e., the EXT_STMT on line 5 instead of three, so that when the debugger stops the state of variables is correct. If it would stop earlier, only some of the code looks like it has been run, but the state of the variables looks like after more code (on future lines) have been run.

But then again, $x *never* gets set in the first place, so its value doesn't make it into the symbol table that Xdebug can access to show its value.

Is there a way to find out whether $x has been optimised out? gdb does this as well, and I think that would be more useful to have.
 [2017-10-21 05:21 UTC] laruence@php.net 
but L3-L4 has been optimized out....
 [2017-11-06 22:43 UTC] derick@php.net 
I know that, but from a user's point of view, that means that stopping *after* all these lines makes more sense. Otherwise a debugger would stop before it looks to the user that following lines (L3/L4) have been executed.
 [2017-11-10 17:16 UTC] derick@php.net 
I would love for this to be resolved. By knowing that an oparray has been optimised (by reading a flag), AND having the EXT_STMTs to end up on the logically right place. Otherwise, debugging usability when opcache is enabled is going to be a very annoying affair, especially when 7.3 comes around.
 [2017-11-21 13:10 UTC] derick@php.net 
Ping :-)
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved. 		Last updated: Wed Jun 23 06:01:25 2021 UTC