> > To be honest, I haven't seen a 'slow' memory leak in a long time -- except > when using fgetcsv which has had a reported memory leak since ~2012 > somewhere on the old bug tracker. (I lost the link to it and don't even > remember how to get to the tracker or if it still exists.) I haven't > checked if it has been fixed since 8.2, but I've seen a couple of reports > of it on r/php a couple of times in the last couple of years. >
A significant number of production environments still run PHP 7.4. Also, beyond the standard extensions, many installations rely on third-party or custom C extensions for specialized tasks (e.g., image processing, machine learning, or connections to external systems). Even a small bug in those C bindings can cause slow leaks that accumulate over multiple requests. In these cases, a process-level memory limit (checked after each request) can help avoid excessive memory growth without waiting on a fix or implementing a complicated workaround. Though it might be rare in core PHP these days, the fact that such issues can arise (especially in non-core extensions) is one of the main reasons some users might like a pm.max_memory mechanism.
