Unknown memory leak in PHP 8.2 FPM #13775

jreklund · 2024-03-21T13:49:28Z

Description

This is an follow up on the issue hi-jacking I did earlier (sorry!). I haven't been able to replicate the issue in development or on our test servers during this time. So I tried a memory profiler on the production server, without any luck. Now I need some new advice from some experts!
#8646 (comment)

After running our application for about an hour we start to see an unhealthy amount of RAM usage. Fast forward a couple of hours and our sever will run out of RAM and start writing to disk instead.

PHP versions tested: 8.2.17, 8.2.14, 8.2.12, 8.2.9, 8.2.8, 8.2.7, 8.2.5, 8.2.4
Configuration: #8646 (comment)

sudo add-apt-repository ppa:ondrej/php
sudo apt update -y
sudo apt install php8.1-common php8.1-fpm php8.1-gd php8.1-mysql php8.1-mbstring php8.1-intl php8.1-xml php8.1-redis php8.1-curl

12 days with PHP 8.1.27 and we utilize 1.3 GB of RAM. Same utilization can be seen using PHP 5.6 - 8.1.

Around 3 hours with PHP 8.2.17 and we utilize 4.5 GB of RAM. This will build up to use all available memory.

I tried to use valgrind massif tool to locate the issue, but it's stable for 7 hours.

I have made two runs, using these settings, they give us the same behavior.
sudo valgrind --tool=massif /usr/sbin/php-fpm8.2
sudo valgrind --tool=massif /usr/sbin/php-fpm8.2 --nodaemonize --fpm-config /etc/php/8.2/fpm/php-fpm.conf

    MB
4.480^                                #                                       
     |                                #    :::::::::::@:::::::::::::::::@:@:  
     |                                #::::: :: : ::: @:::: ::: :::: :::@:@:: 
     |                                #:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                                #:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                               @#:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                               @#:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                               @#:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                               @#:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                              @@#:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                              @@#:  :: :: : ::: @:::: ::: :::: :::@:@:: 
     |                              @@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |                             @@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |                         ::::@@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |                      :::::: @@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |             ::::::::::::::: @@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |          :@::        :::::: @@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |       ::::@::        :::::: @@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |       : ::@::        :::::: @@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
     |     ::: ::@::        :::::: @@@#:  :: :: : ::: @:::: ::: :::: :::@:@:::
   0 +----------------------------------------------------------------------->Mi
     0                                                                   121.6

Number of snapshots: 52
 Detailed snapshots: [6, 16, 17, 18, 19 (peak), 30, 45, 47]

@nielsdos You helped me out before and stated there was another way of using a memory profiler. I didn't see any memory leak using Valgrid thought. But these servers fail 100% of time not using Valgrid.

Did you observe memory leaking behaviour of this run? If yes, that means the problem is somehow not originating from a persistent allocation, and we can give instructions on how to include request memory inside the graphs.

Is it still worth tracking request?

If not, I will start testing our application with PHP 8.2.0 to see if it's compatible before going the git-bisect route.

PHP Version

8.2.17

Operating System

Ubuntu 22.04.4

The text was updated successfully, but these errors were encountered:

nielsdos · 2024-03-21T16:57:43Z

Do you use any third party extensions as well? If yes, I wonder if there may be a leak there too.

Given the information you gave and the tests you did with Valgrind and massif, it seems indeed persistent allocations are not the problem.

I'd say it is worth trying to track request allocations too. To do so, you need to set the environment variable USE_ZEND_ALLOC to 0. This disables Zend's allocator and uses system malloc instead. This will make request allocations visible to Valgrind and massif.
Beware that this may reduce the performance of your code by a few percentage points though.

Edit: although Zend's memory manager should clean up unfreed memory after request shutdown...

jreklund · 2024-03-22T15:28:21Z

We are using php-redis, other than that I would say it's vanilla/core extensions.

Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
hash
iconv
igbinary
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
random
readline
redis
Reflection
session
shmop
SimpleXML
sockets
sodium
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zlib

I have now made a 6,5 hour Valgrind test with USE_ZEND_ALLOC disabled, and according to "htop" I can see a larger memory consumption, but nothing obvious to my eyes in the massif logs. It was a slow build-up and nothing like we use it normally, but over time I guess it would fill up.

    MB
4.481^                                  #                                     
     |                                  #    :::::::::::@@@::@:::::::@::::::: 
     |                                  #::::: :::::::::@ @: @: :::::@: ::::: 
     |                                  #: ::: :::::::::@ @: @: :::::@: ::::: 
     |                                  #: ::: :::::::::@ @: @: :::::@: ::::: 
     |                                  #: ::: :::::::::@ @: @: :::::@: ::::: 
     |                                @@#: ::: :::::::::@ @: @: :::::@: ::::: 
     |                                @ #: ::: :::::::::@ @: @: :::::@: ::::: 
     |                                @ #: ::: :::::::::@ @: @: :::::@: ::::: 
     |                               @@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |                               @@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |                               @@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |                              :@@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |                          ::@::@@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |                       :::: @ :@@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |                       :::: @ :@@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |          ::::@@@@@@@@@:::: @ :@@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |       :::::: @        :::: @ :@@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |       : :::: @        :::: @ :@@ #: ::: :::::::::@ @: @: :::::@: ::::::
     |     ::: :::: @        :::: @ :@@ #: ::: :::::::::@ @: @: :::::@: ::::::
   0 +----------------------------------------------------------------------->Mi
     0                                                                   116.5

massif.out.zip <-- download logs here

I read in Generating a valgrind log that you can enable ZEND_DONT_UNLOAD_MODULES, is that for e.g. tracking third party extensions like redis?

nielsdos · 2024-03-22T16:07:46Z

I don't really notice anything weird, but that data . I'm sorry, but I don't really have an idea what might be going on.
It's going to be very hard also without a reproducer. Bisecting is an option but might be painful to go through. The advantage is that we might get an exact commit though where it broke.

I read in Generating a valgrind log that you can enable ZEND_DONT_UNLOAD_MODULES, is that for e.g. tracking third party extensions like redis?

The allocations will be tracked in any case, but the advantage of using this environment variable is that modules will not be unloaded and therefore symbol names will be visible in stack traces of third party modules.

jreklund · 2024-03-22T16:17:24Z

Thanks for taking a look! I haven't been able to find a reproducer, so next step will be set up a test environment to learn how to make our production environment co-exist with a manually built PHP.

It looks like it's only 10 steps to find the correct commit, but we will need to run the good one for a while, so will take some time for me to set it up.

AFAIK, this is the correct way to start testing it:

git clone https://github.com/php/php-src.git
git checkout php-8.2.4
git bisect start
git bisect bad
git bisect good php-8.1.27
# Bisecting: a merge base must be tested
# [0f21cbc57c0f210cc5ea35b78f354cf2e0949e0e] Fix GH-10715: phpdbg heap buffer overflow -- by misuse of the option "--run"
# build PHP
git bisect good/bad
# (repeat from build PHP)

nielsdos · 2024-03-22T16:26:48Z

AFAIK, this is the correct way to start testing it:

That looks right. It's possible you may need to re-run buildconf and configure too when building PHP, during bisection, because internal APIs and build files changed between PHP 8.1 and PHP 8.2.

crrodriguez · 2024-03-22T18:55:45Z

https://github.com/jemalloc/jemalloc/wiki/Use-Case:-Leak-Checking tried that ? should work if you preload jemalloc AND USE_ZEND_ALLOC=0

nielsdos · 2024-03-22T19:36:20Z

https://github.com/jemalloc/jemalloc/wiki/Use-Case:-Leak-Checking tried that ? should work if you preload jemalloc AND USE_ZEND_ALLOC=0

That doesn't really work properly, see #10670 for why

github-actions · 2024-04-06T00:06:18Z

No feedback was provided. The issue 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. Thank you.

jreklund · 2024-05-31T07:51:09Z

Hi! It took me a while but I have now successfully manage to find where our issue started. Don't know which extension that triggers it yet, but it's one of these; pcntl zlib sodium gd. In these test we don't use any methods from pcntl zlib sodium, but PHP may use it internally(?).

17aa81a5e22d4b8d1ffd7c89cb641939b4f6b7db is the first bad commit
commit 17aa81a5e22d4b8d1ffd7c89cb641939b4f6b7db
Author: Dmitry Stogov <dmitry@zend.com>
Date:   Thu Jun 30 10:49:24 2022 +0300

    Allocate JIT bufer close to PHP .text segment to allow using direct IP-relative calls and jumps (#8890)

    This implementation is based on https://github.com/php/php-src/pull/8618 developed by Su Tao, Wang Xue, Chen Hu and Lizhen Lizhen.

 ext/opcache/shared_alloc_mmap.c | 72 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

I have been running PHP 8.2.19 with the above code removed (and it's modifications) for 3 days without any sign of memory leaks. I'm using a minimum build for our CDN right now, haven't build it with all extensions we require for www.

I did all testing with the following configuration and settings.

./configure --prefix=/usr/local/phpdev --with-config-file-path=/usr/local/phpdev/etc --with-config-file-scan-dir=/usr/local/phpdev/etc/conf.d --disable-debug --enable-option-checking=fatal --enable-fpm --with-mysqli=mysqlnd --enable-sysvsem --enable-sysvshm --enable-sysvmsg --without-sqlite3 --disable-pdo --disable-phar --disable-posix --with-curl --enable-exif --enable-gd --with-webp --with-jpeg --with-webp --with-avif --enable-intl --enable-mbstring --with-openssl --disable-phpdbg --with-fpm-systemd --with-fpm-user=www-data --with-fpm-group=www-data --enable-pcntl --with-zlib --with-sodium --with-password-argon2 --with-external-gd

cp /opt/php/php-src/php.ini-production /usr/local/phpdev/etc/php.ini
cp /opt/php/php-src/sapi/fpm/php-fpm.conf /usr/local/phpdev/etc/php-fpm.conf
cp /opt/php/php-src/sapi/fpm/www.conf /usr/local/phpdev/etc/php-fpm.d/www.conf
cp /opt/php/php-src/sapi/fpm/php-fpm.service /lib/systemd/system/phpdev-fpm.service

/lib/systemd/system/phpdev-fpm.service

#ProtectSystem=full

/usr/local/phpdev/etc/php-fpm.d/www.conf

pm = static
pm.max_children = 30
listen = /usr/local/phpdev/var/run/php-fpm.sock
listen.owner = www-data
listen.group = www-data

mkdir /usr/local/phpdev/etc/conf.d

/usr/local/phpdev/etc/conf.d/10-opcache.ini

; configuration for php opcache module
; priority=10
zend_extension=opcache.so
opcache.jit=off

/usr/local/phpdev/etc/conf.d/30-geeks.ini

expose_php = Off
session.gc_probability = 0

# General
date.timezone = Europe/Stockholm

# File upload
file_uploads = Off

# Exec
disable_functions = system, exec, shell_exec, passthru, phpinfo, show_source, highlight_file, popen, proc_open, fopen_with_path, dbmopen, dbase_open, putenv, chdir, rmdir, rename, filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo

[PHP Modules]
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
hash
iconv
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
random
Reflection
session
SimpleXML
sodium
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
Zend OPcache
zlib

[Zend Modules]
Zend OPcache

I will let this PHP 8.2.19 test running over the weekend and after that try to remove one extension at the time to pinpoint which of pcntl zlib sodium gd we have a problem with. Hopefully we don't have any issues with other extensions we require that I haven't tested yet.

nielsdos · 2024-05-31T16:34:15Z

Thanks for the reporting!
That would mean the issue is in opcache. Does the issue persist if you put that commit back in but disable opcache?

jreklund · 2024-06-01T10:19:10Z

I haven't done a test where opcache has been disabled or not loaded. Going to do a test on Monday.

You want me not to load the extension?

; configuration for php opcache module
; priority=10
;zend_extension=opcache.so
;opcache.jit=off

Or load it and not enable it?

opcache.enable=0
opcache.enable_cli=0

nielsdos · 2024-06-01T10:38:03Z

Thanks!
Not loading the extension will give the most reliable result.

jreklund · 2024-06-04T13:38:14Z

I have now done a 30 hours test with the branch PHP-8.2.19 (reverting our local changes) without loading opache and it works without issues. No memory leaks. :)

nielsdos · 2024-06-04T21:18:14Z

Thanks a lot for the info, it's very peculiar.
The JIT buffer code you patch is only executed once on startup, and it just determines the "ideal" location to put some reserved memory. I don't understand yet how that can create a memory leak, it could of course be a side effect of that code.
I tried for a little over an hour with a configuration that closely matches yours to try to get a leak but I couldn't.
I'll revisit this later
Although in my search for the issue I did find a crash bug (#14471)

jreklund · 2024-06-05T13:27:39Z

Thanks for taking the time trying to find the bug! I made two new tests today where i first removed pcntl and later on zlib. Both tests resulted in memory leaks. Will remove sodium on Monday and see if it's a combination of opcache + some other extension.

nielsdos · 2024-06-05T15:34:05Z

Thanks, that narrows it down even more but at this point I'm convinced it's somehow in opcache. Of course more data is better to help diagnose this!

DPlachkov1991 · 2024-06-23T23:19:17Z

Thanks for taking the time trying to find the bug! I made two new tests today where i first removed pcntl and later on zlib. Both tests resulted in memory leaks. Will remove sodium on Monday and see if it's a combination of opcache + some other extension.

Did you manage to find out that the reason is and if there is some fix? We transitioned from php 7.4 to 8.2 and now all of a sudden our server crashes for no reason - and the "no reason" seems to be we are running out of RAM

arnaud-lb · 2024-06-24T17:52:17Z

Could you share the contents of /proc/$pid/maps for one of the processes with a high memory usage?

What is the value of the opcache.memory_consumption setting?

One possible cause may be that we override an existing mapping due to a race condition or a mistake in 17aa81a. To check this, could you replace MAX_FIXED with MAX_FIXED|MAP_FIXED_NOREPLACE in https://github.com/php/php-src/blob/17aa81a5e22d4b8d1ffd7c89cb641939b4f6b7db/ext/opcache/shared_alloc_mmap.c, like this ?

diff --git a/ext/opcache/shared_alloc_mmap.c b/ext/opcache/shared_alloc_mmap.c
index 92d089bb96c..b158ff30199 100644
--- a/ext/opcache/shared_alloc_mmap.c
+++ b/ext/opcache/shared_alloc_mmap.c
@@ -203,13 +203,13 @@ static int create_segments(size_t requested_size, zend_shared_segment ***shared_
 # ifdef MAP_HUGETLB
 		size_t huge_page_size = 2 * 1024 * 1024;
 		if (requested_size >= huge_page_size && requested_size % huge_page_size == 0) {
-			p = mmap(hint, requested_size, flags, MAP_SHARED|MAP_ANONYMOUS|MAP_HUGETLB|MAP_FIXED, -1, 0);
+			p = mmap(hint, requested_size, flags, MAP_SHARED|MAP_ANONYMOUS|MAP_HUGETLB|MAP_FIXED|MAP_FIXED_NOREPLACE, -1, 0);
 			if (p != MAP_FAILED) {
 				goto success;
 			}
 		}
 #endif
-		p = mmap(hint, requested_size, flags, MAP_SHARED|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
+		p = mmap(hint, requested_size, flags, MAP_SHARED|MAP_ANONYMOUS|MAP_FIXED|MAP_FIXED_NOREPLACE, -1, 0);
 		if (p != MAP_FAILED) {
 			goto success;
 		}

jreklund · 2024-06-25T11:04:33Z

Did you manage to find out that the reason is and if there is some fix? We transitioned from php 7.4 to 8.2 and now all of a sudden our server crashes for no reason - and the "no reason" seems to be we are running out of RAM

Not yet. I have disabled pcntl, zlib and sodium. Leaving only gd as an external part. Haven't done a recent test without it.

@arnaud-lb Thanks for the code suggestion, I will run a test tomorrow and get back to you.

jreklund · 2024-06-26T14:54:33Z

No dice. We got memory leak with the new build.

/proc/$pid/maps from a sub-process reaching 194 MB:
php.maps.txt

opcache.memory_consumption => 128 => 128

DPlachkov1991 · 2024-06-26T15:17:31Z

No dice. We got memory leak with the new build.

/proc/$pid/maps from a sub-process reaching 194 MB: php.maps.txt

opcache.memory_consumption => 128 => 128

Would turning opcache off fix the issue temporary, while this is being looked at?

jreklund · 2024-06-27T07:17:21Z

Would turning opcache off fix the issue temporary, while this is being looked at?

I have no knowledge of your application(s) or settings. For our specific issue you can solve it by disabling OPcache. PHP 8.1 reaches end of life 2025-12-31 and is a viable option until the bug or coding error is resolved.

arnaud-lb · 2024-07-03T15:10:26Z

Thank you @jreklund. One thing noticeable in the memory mapping is that the opcache shm is allocated just next to the heap:

...  85 TiB gap (0x55a781000000) ...
 0x000055a781000000-0x000055a781136000 (  1 MiB) r--p /usr/local/phpdev/sbin/php-fpm
 ... 808 KiB gap (0xca000) ...
 0x000055a781200000-0x000055a781669000 (  4 MiB) r-xp /usr/local/phpdev/sbin/php-fpm
 ...   1 MiB gap (0x197000) ...
 0x000055a781800000-0x000055a782122000 (  9 MiB) r--p /usr/local/phpdev/sbin/php-fpm
 ...   2 MiB gap (0x220000) ...
 0x000055a782342000-0x000055a782400000 (760 KiB) r--p /usr/local/phpdev/sbin/php-fpm
 0x000055a782400000-0x000055a782405000 ( 20 KiB) rw-p /usr/local/phpdev/sbin/php-fpm
 0x000055a782405000-0x000055a782428000 (140 KiB) rw-p 
 ...  19 MiB gap (0x13a9000) ...
 0x000055a7837d1000-0x000055a783a98000 (  2 MiB) rw-p [heap]
 0x000055a783a98000-0x000055a783bf2000 (  1 MiB) rw-p [heap]
 ...  56 KiB gap (0xe000) ...
 0x000055a783c00000-0x000055a78bc00000 (128 MiB) rw-s /dev/zero <-- opcache, presumably (128MiB, shared, anon)
 ...  41 TiB gap (0x29902adf6000) ...
 0x00007f37b69f6000-0x00007f37b7200000 (  8 MiB) rw-p 
 ...   2 MiB gap (0x27c000) ...
 0x00007f37b747c000-0x00007f37bf400000 (127 MiB) rw-p 
 ...   2 MiB gap (0x297000) ...
 0x00007f37bf697000-0x00007f37c0c00000 ( 21 MiB) rw-p 
 ...  52 KiB gap (0xd000) ...
 0x00007f37c0c0d000-0x00007f37c1e30000 ( 18 MiB) rw-p 
 ... 124 KiB gap (0x1f000) ...
 0x00007f37c1e4f000-0x00007f37c2200000 (  3 MiB) rw-p 
 ...  44 KiB gap (0xb000) ...
 0x00007f37c220b000-0x00007f37c2970000 (  7 MiB) rw-p

from experimentation, this will not prevent malloc() from working, however it will use a separate memory mapping, not labelled [heap]. This may be disrupting some memory management routine, possibly in one of the shared libraries.

I'm not sure why the opcache SHM is allocated so close to the heap. This should not happen without a hint, so we may be setting a wrong hint here.

arnaud-lb · 2024-07-03T15:16:41Z

Looking at the current code, the mmap location may be caused by this workaround: https://github.com/php/php-src/blob/ec277ce7fe1e7b7f98e270198826fc1432cdcb3d/ext/opcache/shared_alloc_mmap.c#L68C1-L79C4. This is unexpectedly causing the function to return a hint when it would otherwise return no hint.

Edit: The workaround is not an issue. The end of the heap is less than 4GiB away from the .text segment, so the free segment after the heap is a good candidate.

arnaud-lb · 2024-07-03T17:12:48Z

Could you test with this patch applied? https://patch-diff.githubusercontent.com/raw/php/php-src/pull/14793.diff

This is a backport of a2af8ac from 8.3 + a fix to prevent placing the opcache shm segment just after the heap.

Please also share the content of /proc/$pid/maps again with this patch applied.

jreklund · 2024-07-04T16:07:09Z

Hi! Your latest patch seem stable. Have been running it for 8 hours now. Will leave it over night.

/proc/$pid/maps from a sub-process reaching 80 MB:
php.3107394.maps.txt

arnaud-lb · 2024-07-04T22:38:30Z

Great! I will see if we can merge this, then.

jreklund · 2024-07-05T07:44:06Z

No leaks after around 24 hours, so no long time surprises either. 🎉

Will keep it running for around 8 hours more before I switch back. Will be going on vacation and don't want any surprises.

Thank you everyone for your help with my issue and development of PHP in general!

kanevbg · 2024-07-05T09:59:34Z

Great job. I know that PHP 8.1 is out of active support, but is there any chance that being merged for 8.1 too as being fundamental memory issue? Will be great to get it merged at least in 8.1 too :)

jreklund · 2024-07-05T11:01:56Z

@kanevbg This specific problem don't exists in PHP 8.1 or earlier. The code that caused the problem (for us) was introduced in PHP 8.2.

DPlachkov1991 · 2024-07-05T11:17:57Z

Great! I will see if we can merge this, then.

Was this released with PHP Version 8.2.21 04 Jul 2024(yesterday) or will it be on a later stage?

nielsdos · 2024-07-05T11:31:24Z

Was this released with PHP Version 8.2.21 04 Jul 2024(yesterday) or will it be on a later stage?

No, it will be part of a future release of 8.2.x.

arnaud-lb · 2024-07-22T17:40:48Z

#14793 has been merged.

This prevents the opcache SHM from being allocated too close to the heap in most cases, which is deemed to trigger the memory leak.

Non-PIE builds may still allocate the opcache SHM just after the heap when JIT is enabled, but it may be possible to fix that as well if we get more insights regarding the root cause.

jreklund · 2024-07-22T18:15:53Z

Thanks! Will try out the official patch in 3 weeks, when I get back to work. Hopefully I or someone else will find the real cause of the problem in the future.

cpernot-hf · 2024-08-02T09:03:18Z

@arnaud-lb #14793 does not seem to have been merged, but only closed.

The code does not appear in the PHP-8.2.2 tag : https://github.com/php/php-src/blob/PHP-8.2.22/ext/opcache/shared_alloc_mmap.c#L48

Do you have more information ?

nielsdos · 2024-08-02T16:24:44Z

@cpernot-hf The 8.2.22 version was tagged before the fix was merged in to the 8.2.x branch. The fix will be included in 8.2.23 which will be released in september. See

php-src/NEWS

Lines 32 to 33 in dc670cb

    
           . Fixed bug GH-13775 (Memory leak possibly related to opcache SHM placement). 
        
             (Arnaud, nielsdos)

jreklund · 2024-08-09T13:55:55Z

I'm back from vacation and have been evaluated the new fix available in PHP 8.2 branch and it works without issues. Have been running it for over 3 days.

jreklund added Bug Status: Needs Triage labels Mar 21, 2024

nielsdos added Status: Needs Feedback and removed Status: Needs Triage labels Mar 21, 2024

github-actions bot added Status: Needs Triage and removed Status: Needs Feedback labels Mar 22, 2024

nielsdos added Status: Needs Feedback and removed Status: Needs Triage labels Mar 22, 2024

github-actions bot added Status: Needs Triage and removed Status: Needs Feedback labels Mar 22, 2024

nielsdos added Status: Needs Feedback and removed Status: Needs Triage labels Mar 22, 2024

github-actions bot closed this as completed Apr 6, 2024

github-actions bot removed the Status: Needs Feedback label Apr 6, 2024

nielsdos reopened this May 31, 2024

arnaud-lb mentioned this issue Jul 3, 2024

Do not create the opcache shm mapping too close to the heap #14793

Closed

arnaud-lb closed this as completed in 929536b Jul 22, 2024

Unknown memory leak in PHP 8.2 FPM #13775

Unknown memory leak in PHP 8.2 FPM #13775

Comments

jreklund commented Mar 21, 2024

Description

PHP Version

Operating System

nielsdos commented Mar 21, 2024 • edited Loading

jreklund commented Mar 22, 2024

nielsdos commented Mar 22, 2024

jreklund commented Mar 22, 2024

nielsdos commented Mar 22, 2024

crrodriguez commented Mar 22, 2024

nielsdos commented Mar 22, 2024

github-actions bot commented Apr 6, 2024

jreklund commented May 31, 2024

nielsdos commented May 31, 2024

jreklund commented Jun 1, 2024

nielsdos commented Jun 1, 2024

jreklund commented Jun 4, 2024

nielsdos commented Jun 4, 2024 • edited Loading

jreklund commented Jun 5, 2024

nielsdos commented Jun 5, 2024

DPlachkov1991 commented Jun 23, 2024

arnaud-lb commented Jun 24, 2024

jreklund commented Jun 25, 2024

jreklund commented Jun 26, 2024

DPlachkov1991 commented Jun 26, 2024

jreklund commented Jun 27, 2024

arnaud-lb commented Jul 3, 2024

arnaud-lb commented Jul 3, 2024 • edited Loading

arnaud-lb commented Jul 3, 2024 • edited Loading

jreklund commented Jul 4, 2024

arnaud-lb commented Jul 4, 2024

jreklund commented Jul 5, 2024

kanevbg commented Jul 5, 2024

jreklund commented Jul 5, 2024

DPlachkov1991 commented Jul 5, 2024

nielsdos commented Jul 5, 2024

arnaud-lb commented Jul 22, 2024

jreklund commented Jul 22, 2024

cpernot-hf commented Aug 2, 2024

nielsdos commented Aug 2, 2024

jreklund commented Aug 9, 2024

nielsdos commented Mar 21, 2024 •

edited

Loading

nielsdos commented Jun 4, 2024 •

edited

Loading

arnaud-lb commented Jul 3, 2024 •

edited

Loading

arnaud-lb commented Jul 3, 2024 •

edited

Loading