We currently reserve 10 KiB of memory which we free when handling a OOM error, however this is in many cases way to small. This is especially try when extremely memory constrained and the OOM is triggered by allocating just a tiny bit of extra memory from PHP.

For example when testing with:

$foo = str_repeat('x', 1024 * 1024 * 1024);

This doesn't need the reserved memory since a huge block of memory is being allocated and fails which results in the full memory never being allocated.

In contrary when testing with:

$array = [];
for ($i = 0; $i < 100000000; ++$i) {
    $array[] = str_repeat('a', 100);
}

Here the memory is being allocated in tiny chunks, so when PHP runs out of memory it becomes prominent that the 10 KiB of reserved memory is way to little. From my testing we'd need 30-60x that amount to handle sending a relatively simple payload.

So the solution is to increase the memory limit (once) and use that extra headroom to send the OOM event, I've chosen for 2 MiB, from my testing I think 2 MiB is usually just enough but to be a little on the safe side I've opted for 5 MiB. This value is configurable if needed and this behavior can also be completely disabled if required.

To configure this behavior you can do the following before running \Sentry\init(...):

// The amount of reserved memory every request (in bytes), this has to be a positive integer amount of bytes. Defaults to 16 KiB
$errorHandler = \Sentry\ErrorHandler::registerOnceFatalErrorHandler(16 * 1024);
// The amount of memory in bytes to increase the `memory_limit` to when handling a out of memory error, can also be set to `null` to disable increasing the `memory_limit`. Defaults to 5 MiB
$errorHandler->setMemoryLimitIncreaseOnOutOfMemoryErrorInBytes(5 * 1024 * 1024);

I think we would also be able to shrink the reserved memory we are currently holding but since it's already very little I think it's safe to leave the value like it is. As it turns out we actually need a little more for the regex matching to work correctly on some configurations so I've upped it very slightly by default.

Once accepted I will also port this to the new 4.x branch which suffers from the same problems.

I've also had to ignore some phpstan errors caused by a dependency update.