Bug #66773 [Com]: Autoload with Opcache allows importing conflicting class name to namespace

From: Date: Thu, 31 Mar 2016 10:12:18 +0000
Subject: Bug #66773 [Com]: Autoload with Opcache allows importing conflicting class name to namespace
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-200254@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=66773&edit=1 ID: 66773 Comment by: klein dot shaked+php at gmail dot com Reported by: carl dot vuorinen at w3 dot fi Summary: Autoload with Opcache allows importing conflicting class name to namespace Status: Assigned Type: Bug Package: opcache Operating System: Linux (Ubuntu) PHP Version: 5.5.9 Assigned To: dmitry Block user comment: N Private report: N New Comment: Hey, I have tried the attached patch: $ /usr/bin/php-backup -v PHP 7.0.4-6+deb.sury.org~trusty+5 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies $ /usr/bin/php-backup execute.php PHP Fatal error: Cannot use Other\Bar as Bar because the name is already in use in /php7test/some_foo.php on line 5 Fatal error: Cannot use Other\Bar as Bar because the name is already in use in /php7test/some_foo.php on line 5 $ php -v PHP 7.1.0-dev (cli) (built: Mar 31 2016 09:45:43) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies $ php execute.php self: Some\Bar parent: Other\Bar $ It seems like it works with the gist example. Having said that, it's hard to say if all cases are covered, plus I did have segfault while compiling (and I have filed a bug) which I am not sure if it was related or not. Previous Comments: ------------------------------------------------------------------------ [2016-03-24 12:25:56] klein dot shaked+php at gmail dot com Hey, What is the status of this issue? This is still happening using the gist above and also happened on one of our php7 hosts on production. $ php -v PHP 7.0.4-6+deb.sury.org~trusty+5 (cli) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies uname -a "Linux dev 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux" I have checked PHP's source code but haven't seen the patch there. Any idea how this can be resolved? Thanks ------------------------------------------------------------------------ [2016-01-13 10:10:23] dmitry@php.net The patch (for PHP-7.0), attached to the bug report, removes error without opcache as well. Please review (I'm not sure about all possible consequences). ------------------------------------------------------------------------ [2015-12-27 13:19:14] incubeftw at gmail dot com Bug still persists in PHP 7.0, 7.0.1, 7.1-dev ------------------------------------------------------------------------ [2015-12-14 10:55:02] pawel dot zegardlo at bm dot pl @dmitry - what is the state of this bug? it has been fixed in php 7 or another version? which behaviour is now valid? ------------------------------------------------------------------------ [2015-07-06 04:22:57] kernins at gmail dot com >Isn't the "expected" error behavior here directly in conflict with the >documentation? Absolutely! The actual bug here is the "expected" behaviour itself. The code in some_foo.php from test example is perfectly valid as imports are _per_file_, not per process or thread. Imports have precedence and allows to "shadow" classes from current NS, and they shouldn't care what is already loaded or imported, except from current file. Otherwise, with "expected" behaviour, they not only would be alogical and almost useless, but also a hell to maintain in a big projects. I have a project, that worked perfectly on some older 5.4.x and all previous versions I've used since NS was introduced in 5.3. But after update to 5.5.9 I see exactly the same fatal errors here and there on previously flawlessly working code when runing in CLI. Opcache is and definitely was turned off for CLI SAPI. With FPM, wich has opcache enabled, it worked fine. It seems, that bug was also backported to 5.4 branch - 5.4.34 I have on hand is also affected, but I'm absolutely confident some previous 5.4.x was not. Please, fix this nonsense asap! This bug is pretty annoying ------------------------------------------------------------------------ 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=66773 -- Edit this bug report at https://bugs.php.net/bug.php?id=66773&edit=1

« previous php.bugs (#200254) next »