Sentry crashing on stack overflow

[swbrownuwe]

If a stack overflow occurs in UE and is caught by Sentry, and that overflow left little stack available, Sentry might trigger its own stack overflow while attempting to process it.

I'm not sure exactly why, sentry-native supports setting a stack guarantee and from CMakeLists.txt looks like it should have defaulted to 64k, but from the trace it looks like we had less in practice. This is on 1.0.0-beta.2 built via scripts/build-win64-crashpad.sh.

Stack trace from windbg below,

# Child-SP          RetAddr               Call Site							
00 0000009a`18000ff0 00007fff`caef7069     ntdll!RtlpUnwindPrologue+0x5e4							
01 0000009a`180010a0 00007fff`caef6593     ntdll!RtlpxVirtualUnwind+0x109							
02 0000009a`18001150 00007fff`caea2eda     ntdll!RtlpWalkFrameChain+0x373							
03 0000009a`180017a0 00007fff`caea2e52     ntdll!RtlWalkFrameChain+0x2a							
04 0000009a`180017d0 00007ff6`4a0ee043     ntdll!RtlCaptureStackBackTrace+0x42							
05 0000009a`18001800 00007ff6`49ecf9dd     Application!FWindowsPlatformStackWalk::CaptureStackBackTrace+0xc3 [C:\Application\UE\Engine\Source\Runtime\Core\Private\Windows\WindowsPlatformStackWalk.cpp @ 412]							
06 0000009a`18001c80 00007ff6`4a105e6d     Application!FGenericPlatformStackWalk::StackWalkAndDump+0x3d [C:\Application\UE\Engine\Source\Runtime\Core\Private\GenericPlatform\GenericPlatformStackWalk.cpp @ 208]							
07 0000009a`18002c20 00007ff6`4f656c02     Application!FWindowsPlatformStackWalk::StackWalkAndDump+0x4d [C:\Application\UE\Engine\Source\Runtime\Core\Private\Windows\WindowsPlatformStackWalk.cpp @ 166]							
08 0000009a`18002c50 00007ff6`4f656ad8     Application!PrintCrashLog+0x72 [C:\Application\UE\Application\Plugins\Sentry\Source\Sentry\Private\Windows\WindowsSentrySubsystem.cpp @ 32]							
09 0000009a`18002de0 00007ff6`4f6546f8     Application!FWindowsSentrySubsystem::OnCrash+0x28 [C:\Application\UE\Application\Plugins\Sentry\Source\Sentry\Private\Windows\WindowsSentrySubsystem.cpp @ 54]							
0a 0000009a`18002e20 00007ff6`519e0a7c     Application!FGenericPlatformSentrySubsystem::HandleOnCrash+0x28 [C:\Application\UE\Application\Plugins\Sentry\Source\Sentry\Private\GenericPlatform\GenericPlatformSentrySubsystem.cpp @ 90]							
0b 0000009a`18002e60 00007ff6`519eec84     Application!sentry__backend_new+0x20c							
0c 0000009a`18002ea0 00007fff`c865aa13     Application!crashpad::CrashpadClient::StartHandler+0x2084							
0d 0000009a`18002ff0 00007fff`cafe925f     KERNELBASE!UnhandledExceptionFilter+0x1f3							
0e 0000009a`180030e0 00007fff`cafa6b53     ntdll!RtlUserThreadStart$filt$0+0x3f							
0f 0000009a`18003110 00007fff`cafe623f     ntdll!_C_specific_handler+0x93							
10 0000009a`18003180 00007fff`caef45d7     ntdll!RtlpExecuteHandlerForException+0xf							
11 0000009a`180031b0 00007fff`cafe5b7e     ntdll!RtlDispatchException+0x437							
12 0000009a`18003900 00007ff6`4ca44259     ntdll!KiUserExceptionDispatch+0x2e							
13 0000009a`18004000 00007ff6`4ca45fe2     Application!AActor::GetWorld+0x59 [C:\Application\UE\Engine\Source\Runtime\Engine\Private\Actor.cpp @ 634]					

[tustanivsky]

@swbrownuwe Thank you for bringing this up. It looks like 64KB are being allocated straight away in PrintCrashLog which leads to a secondary crash during on_crash hook processing on Windows.

We'll check if it's feasible to pre-allocate the required amount of memory (e.g. after the SDK initialization) and ensure that the crash stack trace is properly added to logs.

[mujacica]

Should be resolved with 7aa553c. If it still continues happening feel free to reopen the issue.

[swbrownuwe]

It doesn't seem fixed, this should be reopened. Tested on d50b016 (2025-09-29). When checking SetThreadStackGuarantee() on the game thread, it comes back 0, and is why the unhandled exception filter runs out of stack handling the stack overflow. If I manually set it to 64k, it works.

Looking at sentry-native, it looks like sentry__set_default_thread_stack_guarantee() was meant to set the stack guarantee, but it gets called before sentry__init_cached_kernel32_functions() and exits early due to g_kernel32_GetCurrentThreadStackLimits having not been initialized yet.