History log of /php-src/sapi/fpm/tests/gh8646.phpt (Results 1 – 1 of 1)
Revision Date Author Comments
# ff62d117 04-Mar-2023 Niels Dossche <7771979+nielsdos@users.noreply.github.com>

Fix GH-8646: Memory leak PHP FPM 8.1

Fixes GH-8646
See https://github.com/php/php-src/issues/8646 for thorough discussion.

Interned strings that hold class entries can get a cor

Fix GH-8646: Memory leak PHP FPM 8.1

Fixes GH-8646
See https://github.com/php/php-src/issues/8646 for thorough discussion.

Interned strings that hold class entries can get a corresponding slot in map_ptr for the CE cache.
map_ptr works like a bump allocator: there is a counter which increases to allocate the next slot in the map.

For class name strings in non-opcache we have:
- on startup: permanent + interned
- on request: interned
For class name strings in opcache we have:
- on startup: permanent + interned
- on request: either not interned at all, which we can ignore because they won't get a CE cache entry
or they were already permanent + interned
or we get a new permanent + interned string in the opcache persistence code

Notice that the map_ptr layout always has the permanent strings first, and the request strings after.
In non-opcache, a request string may get a slot in map_ptr, and that interned request string
gets destroyed at the end of the request. The corresponding map_ptr slot can thereafter never be used again.
This causes map_ptr to keep reallocating to larger and larger sizes.

We solve it as follows:
We can check whether we had any interned request strings, which only happens in non-opcache.
If we have any, we reset map_ptr to the last permanent string.
We can't lose any permanent strings because of map_ptr's layout.

Closes GH-10783.

show more ...