Bug #79729 [Sus]: Strings missing last character (Apache + OPcache)

From: Date: Tue, 01 Sep 2020 09:02:12 +0000
Subject: Bug #79729 [Sus]: Strings missing last character (Apache + OPcache)
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-228830@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=79729&edit=1 ID: 79729 User updated by: ca at lsp dot net Reported by: ca at lsp dot net Summary: Strings missing last character (Apache + OPcache) Status: Suspended Type: Bug Package: opcache Operating System: Windows Server 2016 Standard -PHP Version: 7.3.19 +PHP Version: 7.3.21 Assigned To: cmb Block user comment: N Private report: N New Comment: Yesterday, we started observing (new) issues despite opcache.optimization_level=0: 1. Error: Class ***\DebugBar contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (***\DebugBarInterface::sendDataInHeaders) - even though DebugBar *does* implement that method. 2. Warning: Use of undefined constant FILE_DIR - assumed 'FILE_DIR' (this will throw an Error in a future version of PHP) - even though this constant *is* defined in a file included using require_once. Again, these issues appeared without any deployment (i.e. changes to the code), but a common denominiator could be that the system had hardly been used in the days preceding these issues. Calling opcache_reset() did not fix these issues, but disabling OPcache and enabling it again did. PS: The system is actually a Hyper-V virtual machine, running on our own hardware. Not that this should make any difference. Previous Comments: ------------------------------------------------------------------------ [2020-07-29 08:32:15] cmb@php.net > This needs to be documented, and preferably also improved. This has been done with <https://github.com/php/php-src/pull/5875>. > […] and will report back in a couple of weeks (if the error does > not occur again). Please report back regardless of the outcome. For the time being, I'm suspending this ticket. ------------------------------------------------------------------------ [2020-07-17 08:11:42] cmb@php.net > Thanks, I have set opcache.optimization_level=0 now and will > report back in a couple of weeks (if the error does not occur > again). Thanks. That might help to track to issue down. Anyhow, my former comment regarding apache2handler startup behavior[1] is wrong. Actually, when running at most a single httpd instance, the message "Opcode handlers are unusable due to ASLR." is not supposed to occur, ever. Thus, this issue may have been reported by a PHP CLI process. > This needs to be documented, and preferably also improved. This holds, though. [1] <https://bugs.php.net/bug.php?id=79729#1594126606> ------------------------------------------------------------------------ [2020-07-13 14:34:34] ca at lsp dot net Thanks, I have set opcache.optimization_level=0 now and will report back in a couple of weeks (if the error does not occur again). ------------------------------------------------------------------------ [2020-07-13 13:25:18] cmb@php.net That might have the same root cause as the truncated identifiers (memory corruption). Did that happen with opcache.optimization_level=0? ------------------------------------------------------------------------ [2020-07-13 12:11:05] ca at lsp dot net We have observed another strange behaviour last Thursday, namely a PDOException: ``` SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '; 'own_req') OR (perms.name = 'process' AND perms.unit ; 'req') ' at line 15, ``` The weird thing is that the corresponding code that generates the SQL conditions actually has "perms_unit =" hardcoded, so "perms_unit ;" should never occur: ``` $sql_perm .= " perms.name = '$name' \n"; $sql_perm .= " AND perms.unit = '$unit' \n $condition"; ``` Note: The $sql_perm variable is used to create the final statement using sprintf, but that shouldn't make any difference. The resulting SQL statement contained the mistake twice, since the code snippet above is part of a loop: ``` (perms.name = 'process' AND perms.unit ; 'own_req') OR (perms.name = 'process' AND perms.unit ; 'req') ``` Again, the problem disappeared after resetting the OPcache. ------------------------------------------------------------------------ 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=79729 -- Edit this bug report at https://bugs.php.net/bug.php?id=79729&edit=1

« previous php.bugs (#228830) next »