php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78147 Memory leak after upgrade to 7.2.19
Submitted: 2019-06-11 19:11 UTC Modified: 2020-08-02 04:22 UTC
Votes:8
Avg. Score:4.6 ± 0.5
Reproduced:8 of 8 (100.0%)
Same Version:8 (100.0%)
Same OS:4 (50.0%)
From: mario dot bandeira at cronobandeira dot com Assigned: cmb (profile)
Status: No Feedback Package: opcache
PHP Version: 7.2.19 OS: Windows Server 2016 Standard
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mario dot bandeira at cronobandeira dot com
New email:
PHP Version: OS:

 

 [2019-06-11 19:11 UTC] mario dot bandeira at cronobandeira dot com
Description:
------------
Server was working ok on 08.06.2019
An upgrade was made to php 7.2.19 on 09.06.2019 at 2am
Problem: Server crashes after period of time (seams related to number of requests).
We could see that a a point of the code a simple echo with variables were giving the error:
[09-Jun-2019 17:43:16 UTC] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 7093009363071360192 bytes) in C:\Inetpub\vhosts\cronobandeira.com\httpdocs\cnr\index.php on line 389
The variable in question was a integer. If we remove that variable from the echo the problem was on the next variable evaluated.
We have checked all system configuration and the only change was the upgrade of php.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-06-11 19:39 UTC] nikic@php.net
Are you using opcache?
 [2019-06-12 08:45 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2019-06-12 14:21 UTC] mendel at spotlightdesign dot com
Same issue, a few more details.

Windows 2012/IIS/Plesk Onyx 17.8.11

Several websites with no recent changes, only change is plesk updating PHP 7.2 to 7.2.19 https://docs.plesk.com/release-notes/onyx/change-log/#contents-17811-mu55

Yes it is using opcache.
 [2019-06-12 14:31 UTC] cmb@php.net
-Status: Feedback +Status: Open -Package: IIS related +Package: opcache -Assigned To: cmb +Assigned To:
 [2019-06-12 14:48 UTC] mario dot bandeira at cronobandeira dot com
Yes, opcache is enabled.
 [2019-06-12 15:43 UTC] mario dot bandeira at cronobandeira dot com
I have made some tests and the problem is on with or without the opcache enabled for the subdomain.
The subdomain (cnr.cronobandeira.com) that originally had the problem (with php 7.2.19) is now running php 7.1.30 without any issues.
 [2019-06-12 16:49 UTC] 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).
 [2019-07-04 16:39 UTC] kris at accuwebhosting dot com
Same issue with PHP 7.2.19 (FastCGI), Windows 2016 server and Plesk.
 [2019-08-02 04:21 UTC] 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-09-17 19:34 UTC] 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
 [2020-07-23 10:39 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-07-23 10:39 UTC] 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?
 [2020-08-02 04:22 UTC] php-bugs at lists dot php dot net
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.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Apr 22 16:01:24 2021 UTC