fix: apply default thread stack guarantee in static builds and the native backend - #1918
Merged
Merged
Conversation
…tive backend Cache kernel32 functions before backend startup in static builds - previously sentry__set_default_thread_stack_guarantee() called from backend startup (crashpad/breakpad/inproc) silently no-oped because GetCurrentThreadStackLimits was not loaded yet. Also apply the default thread stack guarantee in the native backend startup, matching the other backends, so its in-process exception filter can run after a stack overflow.
tustanivsky
added a commit
to getsentry/sentry-unreal
that referenced
this pull request
Jul 27, 2026
The stack guarantee fix branch was rebased for the upstream PR (getsentry/sentry-native#1918); the previously pinned commit no longer exists on any branch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
tustanivsky
added a commit
to getsentry/sentry-unreal
that referenced
this pull request
Jul 27, 2026
The stack guarantee fix branch was rebased for the upstream PR (getsentry/sentry-native#1918); the previously pinned commit no longer exists on any branch.
tustanivsky
added a commit
to getsentry/sentry-unreal
that referenced
this pull request
Jul 27, 2026
The stack guarantee fix branch was rebased for the upstream PR (getsentry/sentry-native#1918); the previously pinned commit no longer exists on any branch.
tustanivsky
added a commit
to getsentry/sentry-unreal
that referenced
this pull request
Jul 27, 2026
The thread stack guarantee fix (getsentry/sentry-native#1918) will be picked up via a separate dependency update PR once it merges upstream.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1918 +/- ##
==========================================
- Coverage 75.71% 75.61% -0.10%
==========================================
Files 93 93
Lines 22034 22034
Branches 3925 3925
==========================================
- Hits 16682 16660 -22
- Misses 4464 4492 +28
+ Partials 888 882 -6 🚀 New features to boost your workflow:
|
tustanivsky
requested review from
JoshuaMoelans,
jpnurmi and
mujacica
and removed request for
jpnurmi
July 27, 2026 07:25
mujacica
approved these changes
Jul 27, 2026
jpnurmi
approved these changes
Jul 27, 2026
1 task
tustanivsky
added a commit
to getsentry/sentry-unreal
that referenced
this pull request
Jul 28, 2026
* Harden integration-test crash uploads in CI The desktop crash test can be flaky because both desktop backends can race the upload on shutdown: crashpad uploads out-of-process while the crashing process is already exiting, and the native out-of-process daemon drains its transport bounded by ShutdownTimeout (default 5000ms), which can be too short for a large envelope or slow link (the same root cause seen dropping crashes on the Xbox native backend). Non-crash tests upload via the SDK transport on sentry_close and hit the same limit. Raise ShutdownTimeout so the native daemon's crash upload and async event uploads have time to drain, and enable CrashpadWaitForUpload so the crashpad legs wait for the crash upload before exiting. Also include the sentry-native database (.sentry-native) in the on-failure artifacts for the Windows and Linux integration tests to simplify diagnosing missing/failed uploads. * Include hidden files so .sentry-native is captured in the artifact actions/upload-artifact skips hidden files by default, which dropped the dotted .sentry-native crash DB (daemon log, minidumps) from the failure artifacts. * Add memory limit util * Raise sentry-native thread stack guarantee in Windows integration tests Stack-overflow crash capture intermittently dies in-process (secondary 0xC0000005, no minidump produced) because the default 64 KiB guarantee is not always enough for UE's handler chain. SENTRY_HANDLER_STACK_SIZE is read by sentry-native at init, so no rebuild is needed. * Bump sentry-native to pick up thread stack guarantee fixes Points the submodule at fix/thread-stack-guarantee-static-init (master + fix): kernel32 caching now precedes backend startup in static builds so the default thread stack guarantee is actually applied, and the native backend now sets it like the other backends do. This should let the in-process handlers survive stack-overflow crashes in the Windows integration tests. * Allow manual dispatch of package-plugin-workflow Dispatched runs get their own concurrency group (run_id fallback), so multiple validation runs can execute in parallel without canceling the PR run. * Filter Android logcat capture to relevant tags in integration tests The crash-capture test intermittently fails with "Expected 1 EVENT_CAPTURED line(s) but found 0": real SauceLabs devices emit thousands of unrelated log lines per second (AuthPII alone was ~8k of the ~10k captured lines), evicting UE's output from the captured log window before the harness reads it. Use app-runner's SAUCE_LOGCAT_FILTER (getsentry/app-runner#53, already in the pinned revision) to filter at capture time. * Drop exact replay duration assertion in integration tests The server computes replay duration from segment timestamps, which shift with crash handling timing (observed 6 vs the sidecar's nominal 5 seconds), so an exact match is inherently flaky. * Update sentry-native pin to reworded fix branch The stack guarantee fix branch was rebased for the upstream PR (getsentry/sentry-native#1918); the previously pinned commit no longer exists on any branch. * Remove workflow_dispatch trigger used for CI validation * Revert sentry-native pin to 0.15.4 The thread stack guarantee fix (getsentry/sentry-native#1918) will be picked up via a separate dependency update PR once it merges upstream. * Remove SENTRY_HANDLER_STACK_SIZE env var * Capture only logs from .sentry-native in failure artifacts Minidumps and envelopes contain process memory of the crashed test app (on Linux even the full environment block), which may hold CI secrets. Restrict the artifact to the daemon logs, which carry the diagnostic value.
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.
Two related issues prevented the Windows thread stack guarantee from protecting crash handling after a stack overflow:
Static builds never applied the guarantee on any backend. In static builds,
sentry_initcached the required kernel32 function pointers (GetCurrentThreadStackLimits,SetThreadStackGuarantee) after backend startup.sentry__set_default_thread_stack_guarantee(), called from the crashpad/breakpad/inproc backend startup, checks those pointers first and silently returns when they areNULL- so no thread ever got a stack guarantee, andSENTRY_HANDLER_STACK_SIZEhad no effect. This PR moves the caching before backend startup.The native backend never requested a guarantee at all. Unlike crashpad/breakpad/inproc,
native_backend_startuphad nosentry__set_default_thread_stack_guarantee()call. Its in-process exception filter does substantially more work on the crashing thread than crashpad's client filter, so running without a guarantee makes stack-overflow capture especially unreliable. This PR adds the same guarded call the other backends use.Related items