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

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: > we recommend to never disable opcache.file_cache_fallback (which it is in your case) I'm a bit confused, because opcache.file_cache_fallback is actually *not* disabled in our case (see OPcache configuration above). I just verified this (both via php -i and a phpinfo() script accessed via Apache, in case these may differ, which they don't seem to). Here's the relevant section from the current output of php -i (coincidentally just after a deployment calling opcache_reset(), hence 0 hits/misses): ``` Zend OPcache Opcode Caching => Up and Running Optimization => Enabled SHM Cache => Enabled File Cache => Disabled Startup => OK Shared memory model => win32 Cache hits => 0 Cache misses => 0 Used memory => 8770936 Free memory => 125446792 Wasted memory => 0 Interned Strings Used memory => 342472 Interned Strings Free memory => 5948536 Cached scripts => 0 Cached keys => 0 Max keys => 7963 OOM restarts => 0 Hash keys restarts => 0 Manual restarts => 0 Directive => Local Value => Master Value opcache.blacklist_filename => no value => no value opcache.consistency_checks => 0 => 0 opcache.dups_fix => Off => Off opcache.enable => On => On opcache.enable_cli => On => On opcache.enable_file_override => Off => Off opcache.error_log => C:\***\opcache_error.log => C:\***\opcache_error.log opcache.file_cache => no value => no value opcache.file_cache_consistency_checks => On => On opcache.file_cache_fallback => On => On opcache.file_cache_only => Off => Off opcache.file_update_protection => 2 => 2 opcache.force_restart_timeout => 180 => 180 opcache.interned_strings_buffer => 8 => 8 opcache.log_verbosity_level => 1 => 1 opcache.max_accelerated_files => 4000 => 4000 opcache.max_file_size => 0 => 0 opcache.max_wasted_percentage => 5 => 5 opcache.memory_consumption => 128 => 128 opcache.mmap_base => no value => no value opcache.opt_debug_level => 0 => 0 opcache.optimization_level => 0x7FFEBFFF => 0x7FFEBFFF opcache.preferred_memory_model => no value => no value opcache.protect_memory => Off => Off opcache.restrict_api => no value => no value opcache.revalidate_freq => 60 => 60 opcache.revalidate_path => Off => Off opcache.save_comments => On => On opcache.use_cwd => On => On opcache.validate_permission => Off => Off opcache.validate_timestamps => On => On ``` PS: The only change I made since the issue ocurred was to set opcache.error_log (and to use rsync --checksum in deployment rather than rsync --times to avoid OPcache possibly being confused by timestamps not reflecting the deployment timestamp). Previous Comments: ------------------------------------------------------------------------ [2020-06-24 12:25:15] cmb@php.net > Events 487 occur several times per day and sound like bug > #79040, which should have been fixed in 7.3.14. That bug was actually why I asked for the exact PHP version (thanks for the info!) The fix addressed potential issues with running diffent SAPIs simultaneously (such as apache2handler and cli). 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. I don't think that these errors are related to the truncated strings, though. [1] <https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.file-cache-fallback> ------------------------------------------------------------------------ [2020-06-24 11:18:01] ca at lsp dot net Just stumbled upon the following errors in the Windows Event Logs: ``` 24.06.2020 08:43:00, Event 487, Zend OPcache Opcode handlers are unusable due to ASLR. Please setup opcache.file_cache and opcache.file_cache_fallback directives for more convenient Opcache usage ... 23.06.2020 20:15:00, Event 0, Zend OPcache Unable to read base address ``` Events 487 occur several times per day and sound like bug #79040, which should have been fixed in 7.3.14. Events 0 occur not more than once per day. The issues started 10 minutes after an Event 487: ``` [24/Jun/2020:08:53:13 +0200] "GET /admin/default*** HTTP/2.0" 302 - [24/Jun/2020:08:53:13 +0200] "GET /admin/index*** HTTP/2.0" 500 921 ``` But there are also two PHP cronjobs running every minute via CLI. ------------------------------------------------------------------------ [2020-06-24 10:47:16] ca at lsp dot net Updated OS. ------------------------------------------------------------------------ [2020-06-24 10:45:55] ca at lsp dot net @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 ``` ------------------------------------------------------------------------ [2020-06-24 10:38:26] cmb@php.net Are you really using PHP 7.3.19, or maybe an older 7.3 version? If the latter, could you check with 7.3.19? Also, do you use mod_php or FCGI; in other words, is about a ZTS (thread-safe) or NTS (non thread-safe) PHP build? ------------------------------------------------------------------------ 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