Repository navigation
feat: add an opt-in memory reserve for the crash handler - #2274
Open
tustanivsky wants to merge 8 commits into
Open
tustanivsky wants to merge 8 commits into
tustanivsky wants to merge 8 commits into
Conversation
Add the SENTRY_CRASH_MEMORY_RESERVE build setting (in KiB, 0 by default) and sentry_options_set_crash_memory_reserve() to override it at runtime.
Map and touch the reserve in sentry_init() before the backend starts, so it is backed by memory when a crash occurs, and release it on close or when init fails. Windows uses VirtualAlloc and Unix uses mmap. Other platforms log a warning when a reserve is requested.
Release it once each backend has decided to handle the crash, so that signals or exceptions that are handed back to a runtime keep it. Breakpad gets a filter callback to release it before the minidump is written, which covers unhandled exceptions, invalid parameters, pure calls and SIGABRT on Windows. The native backend releases it before signaling the daemon, which may share the application's memory budget.
Add an oom-exhaust fixture command that keeps allocating smaller blocks under a Job Object limit until almost no memory is left, and check that inproc and breakpad still capture the crash with a memory reserve. Without the reserve, breakpad writes an empty minidump.
|
inproc walks the stack with dbghelp, which loads symbols on 32-bit and needs more memory than the test reserves in Debug builds.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #2274 +/- ##
==========================================
+ Coverage 75.56% 75.70% +0.13%
==========================================
Files 103 104 +1
Lines 28315 28378 +63
Branches 5203 5208 +5
==========================================
+ Hits 21397 21483 +86
+ Misses 5581 5542 -39
- Partials 1337 1353 +16 🚀 New features to boost your workflow:
|
tustanivsky
marked this pull request as ready for review
October 30, 2026 12:44
tustanivsky
requested review from
JoshuaMoelans,
jpnurmi,
limbonaut and
mujacica
October 30, 2026 12:51
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When an application crashes after it ran out of memory, the crash handler has nothing left to allocate either and fails to capture the crash.
sentry_options_set_crash_memory_reserve()and theSENTRY_CRASH_MEMORY_RESERVEbuild setting (in KiB) reserve memory insentry_init(). Its pages are touched so they are backed by memory, and it is released once a backend has decided to handle a crash: before signaling the daemon in the native backend, in the inproc and crashpad handlers, and from a new breakpad filter callback that runs before the minidump is written. Releasing it after the backends' own checks keeps the reserve for signals that are handed back to a managed runtime.The reserve is disabled by default. Console SDKs can enable it with the build setting; sentry-xbox reserves 8 MB.
The existing
oomtests didn't cover this scenario becausetrigger_oom()doubles the allocation size and crashes on the first failure, which leaves about half of the memory free for the crash handler. The newoom-exhaustfixture command keeps allocating smaller blocks under a Job Object limit until almost no memory is left.Other Considerations
Related Items