You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When PHP hits the configured memory_limit, a fatal error is thrown. The Laravel framework is configured to handle such fatal errors through register_shutdown_function() and frees some memory to allow further processing of the error (about 32k as of https://github.com/laravel/framework/pull/42646/files). When that reserved memory is exceeded again, the process abruptly stops.
I found that this SDK sometimes fails to report out-of-memory errors, most likely due to excessive memory usage during reporting. In our application, errors such as Allowed memory size of x exceeded make it to Sentry only some amount of times. Other times, the process just crashes abruptly with no indication as to what went wrong.
Solution Brainstorm
I suspect that the breadcrumbs and other information that is already stored in the SDK context leading up to the out-of-memory error influence how much memory is used to report the error. Perhaps the SDK can detect out-of-memory errors and somehow limit the amount of memory it consumes to be well under the
The text was updated successfully, but these errors were encountered:
The PHP SDK also keeps a memory buffer (on top of Laravel) and we have tried to make this more reliable already: getsentry/sentry-php#1633 (also ported to 4.x).
I am wondering if both those measures have no effect because Laravel is handling the error and we therefore don't detect it as an OOM event and thus don't take the measure in the PHP SDK to free up our own buffer and perform an additional memory increase.
It's very hard to test and create a definitive test case for this, so many variables 😄
Happy to try and find a more stable solution though. I think the first thing to do is make sure the PHP SDK is aware it is an OOM event and can take it's own measures. If that is not enough we could see if we can limit or drop added event data to make it's capture more reliable.
Problem Statement
When PHP hits the configured
memory_limit
, a fatal error is thrown. The Laravel framework is configured to handle such fatal errors throughregister_shutdown_function()
and frees some memory to allow further processing of the error (about 32k as of https://github.com/laravel/framework/pull/42646/files). When that reserved memory is exceeded again, the process abruptly stops.I found that this SDK sometimes fails to report out-of-memory errors, most likely due to excessive memory usage during reporting. In our application, errors such as
Allowed memory size of x exceeded
make it to Sentry only some amount of times. Other times, the process just crashes abruptly with no indication as to what went wrong.Solution Brainstorm
I suspect that the breadcrumbs and other information that is already stored in the SDK context leading up to the out-of-memory error influence how much memory is used to report the error. Perhaps the SDK can detect out-of-memory errors and somehow limit the amount of memory it consumes to be well under the
The text was updated successfully, but these errors were encountered: