|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2020-06-24 10:18 UTC] ca at lsp dot net
Description:
------------
I observed a very strange behaviour in combination with Apache + OPcache today.
My colleague was using the test instance of our PHP application this morning (no deployment since yesterday), and it was working fine, until suddenly the following error appeared (and didn't disappear anymore):
```
Error: Uncaught --> Smarty: Plugin 'cut_hea' not callable
```
The string "cut_hea" doesn't exist in our code base, but instead comes from a class constant string array containing the element "cut_head":
```
class SmartyModifiers
{
const MODIFIERS = [
"cut_head",
...
];
public static function cut_head( ... )
{
...
}
}
```
This class constant is being used as follows:
```
foreach (SmartyModifiers::MODIFIERS as $modifier) {
$ref = SmartyModifiers::class . '::' . $modifier;
$this->registerPlugin("modifier", $modifier, $ref);
}
```
The error was logged inside the `registerPlugin` method, because `SmartyModifiers::cut_hea` (without the "d") doesn't exist and is therefore not callable.
Now, as if this wasn't strange enough, the corresponding Sentry event also contained the same anomaly:
```
There was 1 error encountered while processing this event
* environmen: Discarded unknown attribute
```
(Note the missing "t" in "environmen" vs. "environment".)
To mitigate the issue, I tried to `opcache_reset()` and restart the Apache server, but both didn't solve the issue. The only solution I found was to disable `zend_extension=php_opcache.dll` temporarily (disable, restart, enable, restart).
Our OPcache configuration is as follows, following the recommendations from [1]:
```
[opcache]
zend_extension=php_opcache.dll
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
```
[1] https://www.php.net/manual/de/opcache.installation.php
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Nov 02 09:00:01 2025 UTC |
@nikic Thanks, I will try that once the issue occurs again (which I hope it does). @cmb The server is running PHP 7.3.19 since 2020-06-11 (but actually the OS is Windows Server 2016 Standard, not Windows 10). ``` $ php --version PHP 7.3.19 (cli) (built: Jun 9 2020 11:54:59) ( ZTS MSVC15 (Visual C++ 2017) x64 ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.19, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.19, Copyright (c) 1999-2018, by Zend Technologies ```> 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.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.