Bug #78147 [Fbk->NoF]: Memory leak after upgrade to 7.2.19

Edit report at https://bugs.php.net/bug.php?id=78147&edit=1 ID: 78147 Updated by: php-bugs@lists.php.net Reported by: mario dot bandeira at cronobandeira dot com Summary: Memory leak after upgrade to 7.2.19 -Status: Feedback +Status: No Feedback Type: Bug Package: opcache Operating System: Windows Server 2016 Standard PHP Version: 7.2.19 Assigned To: cmb Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. Previous Comments: ------------------------------------------------------------------------ [2020-07-23 10:39:19] cmb@php.net I assume that this is a duplicate of bug #78103, which apparently is fixed as of PHP 7.2.20, or can anybody still reproduce this issue? ------------------------------------------------------------------------ [2019-09-17 19:34:56] john at onatlas dot com update from my prior report... php 7.2.21 64 bit stable in my environment Steps to resolve ONE switch to 64 bit php from 32bit TWO disable extension wincache 2.0.0.8, which never had an official build for php 7.2 THREE use mmap_base as mentioned online for Windows FOUR restart Windows A windows server restart was needed once these were applied to php.ini. Even App Pool recycle resulted in lingering failures (I have 5 app pools with php). These directives related to opcache in php.ini now opcache.error_log = "D:\php72x64\tmp\opcache.log" opcache.file_cache="D:\php72x64\tmp\opcache" opcache.log_verbosity_level=2 opcache.mmap_base=0x20000000 Bonus, during unstable trial and error time frame, having the file_cache configured prevented a 500 status, instead logging "Sep 10 16:19:22 2019 (6692): Warning Base address marks unusable memory region (fall-back to file cache)" mmap_base and the removal of wincache seemed to be the primary fix, may try wincache again in future php build, if MS releases official extension ------------------------------------------------------------------------ [2019-08-02 04:21:22] john at onatlas dot com very similar experience! two Windows 2008R2 x64 servers Under Zend Server 2018.0.3 with php 7.2.15 32bit, opcache enabled, no errors, very stable. Upgrade to php 7.2.20 32bit (no more Zend Server), still with opcache enabled, on same two windows servers. After production server runs OK for ~10-20 minutes in load balancer, I get errors from pages that connect to remote servers, maybe 1% of requests. Most common failures... - Uncaught Exception cURL error 6: getaddrinfo() thread failed to start (connect to remote queue service) - [Microsoft][ODBC Driver 17 for SQL Server]SQL Server Network Interfaces: Not enough storage is available to process this command. - fsockopen(): unable to connect to searchengine.local:8080 (An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. When I disable opcache in php 7.2.20, errors stop, but pages are too slow! Tried these variety of opcache directives ONE opcache.enable=1 TWO opcache.optimization_level=0xffffffff THREE opcache.optimization_level=0xffffffff opcache.mmap_base=0x20000000 FOUR opcache.mmap_base=0x20000000 When opcache enabled, with all directives tried, random errors start on server in 10-20 minutes ------------------------------------------------------------------------ [2019-07-04 16:39:35] kris at accuwebhosting dot com Same issue with PHP 7.2.19 (FastCGI), Windows 2016 server and Plesk. ------------------------------------------------------------------------ [2019-06-12 16:49:31] mendel at spotlightdesign dot com PHP error log: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 7810770492979178392 bytes) ... (That's a lot of bytes!!!, Much more than in the other reports posted). Possibly related to https://bugs.php.net/bug.php?id=78103 (as posted by mario on that report). ------------------------------------------------------------------------ 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=78147 -- Edit this bug report at https://bugs.php.net/bug.php?id=78147&edit=1