Event capture performs potentially expensive preparation synchronously on the calling thread. When capture originates from the main thread, repeated production app-hang samples show that this processing can block UI progress long enough to trigger a fatal fully-blocked app hang.
Evidence
- SDK-CRASHES-COCOA-127Z repeatedly samples the main thread in
captureEvent → prepareEvent → applyToEvent while merging scope dictionaries. Ten recent events showed this capture path, across SDK versions 9.20.0 and 9.26.0.
- SDK-CRASHES-COCOA-16P0 repeatedly samples the main thread in
captureEvent → prepareEvent → beforeSend while bridging and inspecting event tags. Ten recent events showed this capture path, across SDK versions 9.20.0 and 9.26.0.
- Both groups are reported as
Fatal App Hang Fully Blocked and contain the UIKit main run loop below the synchronous Sentry capture stack.
Root cause
The public capture call reaches event preparation inline. Scope application, event processors, callbacks, and related transformations therefore execute on whichever thread initiated capture, including the main thread. Large dictionaries or expensive transformations can keep that thread occupied long enough to be detected as an app hang.
This is broader than #7757: that report focused on breadcrumb locking and file I/O, and was closed after the breadcrumb persistence work in 9.26.1. The stacks above do not enter that persistence path.
High-level direction
Move potentially heavy event preparation work away from the calling thread, particularly when capture originates on the main thread, while preserving capture behavior and callback semantics.
via Thomas Hedderwick.
--
View Junior Session [Sentry]
Event capture performs potentially expensive preparation synchronously on the calling thread. When capture originates from the main thread, repeated production app-hang samples show that this processing can block UI progress long enough to trigger a fatal fully-blocked app hang.
Evidence
captureEvent → prepareEvent → applyToEventwhile merging scope dictionaries. Ten recent events showed this capture path, across SDK versions 9.20.0 and 9.26.0.captureEvent → prepareEvent → beforeSendwhile bridging and inspecting event tags. Ten recent events showed this capture path, across SDK versions 9.20.0 and 9.26.0.Fatal App Hang Fully Blockedand contain the UIKit main run loop below the synchronous Sentry capture stack.Root cause
The public capture call reaches event preparation inline. Scope application, event processors, callbacks, and related transformations therefore execute on whichever thread initiated capture, including the main thread. Large dictionaries or expensive transformations can keep that thread occupied long enough to be detected as an app hang.
This is broader than #7757: that report focused on breadcrumb locking and file I/O, and was closed after the breadcrumb persistence work in 9.26.1. The stacks above do not enter that persistence path.
High-level direction
Move potentially heavy event preparation work away from the calling thread, particularly when capture originates on the main thread, while preserving capture behavior and callback semantics.
via Thomas Hedderwick.
--
View Junior Session [Sentry]