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: Assigned
Type: Bug
Package: opcache
Operating System: Windows Server 2016 Standard
PHP Version: 7.3.19
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
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).
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2020-07-07 12:56:46] cmb@php.net
> Other than that, "Opcode handlers are unusable due to ASLR."
> warnings may occur on Windows, so we recommend to never disable
> opcache.file_cache_fallback (which it is in your case); otherwise
> the process exits, which is undesireable.
That's actually nonsense wrt. apache2handler (assuming you're
running a single httpd instance). That error can only occur on
Apache startup, and in that case the base mapping file should be
deleted, and Apache restarted. Or delete the base mapping file
right away before restarting Apache. The base mapping file is in
the temp folder, and its name is
ZendOPcache.MemoryBase@<user>@apache2handler@<md5>
This needs to be documented, and preferably also improved.
------------------------------------------------------------------------
[2020-06-25 13:41:49] ca at lsp dot net
Meanwhile, I opened bug 79735 for the "Call to undefined method" error.
After some consideration though, the root cause could be the same. This is the *complete* log entry
for the current issue in the PHP error log:
```
[24-Jun-2020 06:53:14 UTC] PHP Fatal error: Uncaught --> Smarty: Plugin 'cut_hea' not
callable <--
thrown in C:\***\vendor\smarty\smarty\libs\sysplugins\smarty_internal_method_registerplugin.php on
line 50
```
The short stacktrace suggests that this error occurred in an exception_handler or similar, and maybe
OPcache isn't working properly in that context?
------------------------------------------------------------------------
[2020-06-25 10:30:13] ca at lsp dot net
@cmb Thank you for the docs update, I have set those values now.
Today I observed the following (possibly related) exceptions in the same instance, all in the
context of web requests:
```
10:14:02 CEST
Error: Uncaught Error: Call to undefined method ***\MyDB::searchByCol()
10:20:10 CEST
Error: Uncaught Error: Call to undefined method ***\MyDB::searchByCol()
10:23:33 CEST
Error: Uncaught Error: Call to undefined method ***\MyDB::searchByCol()
11:03:03 CEST
Error: Uncaught Error: Call to undefined method ***\MyDB::searchByCol()
```
(Note: The method MyDB::searchByCol() *does* exist.)
The same issue occurred 3x on June 12, two days after we enabled OPcache (and one day after the
upgrade to 7.3.19).
Unfortunately I had obviously not restarted the Apache server after making the latest config
changes, so the OPcache log verbosity was not sufficient for the web server requests (and possibly
the file_cache value was not yet effective either), so I will have to wait and see if it occurs
again.
One thing I should mention though is that we run multiple branches simultaneously on that test
server:
- C:/app = test app for branch "develop"
- C:/app-review/12345-foo = review app for branch "12345-foo"
So could these issues be related to the fact that there are multiple MyDB.php files? I
wonder if I have to enable opcache.revalidate_path to prevent the wrong file from being
loaded by 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