feat: minidump scope

[timfish]

• Closes Minidump scope sync #1341

The minidump crash event now carries the scope of the thread that crashed, including hubs bound with Hub::run, so a server with one hub per request reports the request that crashed.

Nothing is sent to the crash reporter until the crash. The new on_crash hook in minidumper-child names the crashing OS thread, a parked helper thread serializes that thread's scope with Scope::apply_to_event, and the handler sends it before the dump request. The reporter merges it with the fatal event. This replaces the manual set_user/set_tag/set_extra/add_breadcrumb, which cost one message per scope write.

sentry-core gains a thread-registry feature: Hub::for_os_thread and current_os_thread_id map OS thread ids to the hub current on each thread, kept up to date by SwitchGuard. Zero cost with the feature off.

Linux and Windows: signal safety

The handler runs on the crashing thread (signal handler / exception handler), which may hold the allocator, registry or scope lock. So the handler only does signal-safe work: it sets atomics, unparks the helper (futex / keyed event, no allocation), polls an atomic done flag with 1 ms sleeps, then reads the result with try_lock (which cannot block, because the helper unlocks before it sets done) and writes it to the socket.

Everything else runs on the sentry-minidump-scope helper thread: registry lookup, scope clone, event processors, JSON. It starts at init, because spawning a thread in the handler would allocate. If the crashed thread holds a lock the helper needs, the helper blocks, the handler's wait hits scope_timeout (default 2s) and the minidump event goes out without scope. The worst case is a missing scope, never a missing minidump.

macOS: inline, no helper

crash-handler uses a Mach exception port on macOS. The callback runs on a dedicated handler thread, not the crashing thread, and SIGABRT takes the same path. It is not signal context, so the scope work runs inline. A helper would not work, because the handler suspends every other thread before it calls the callback, and that includes the helper. scope_timeout has no effect here.

Limit: if a suspended thread or the crashed thread held the allocator, registry or scope lock, the inline work blocks on it with no timeout and no dump is requested. I have not seen this in testing.

Details

• Thread ids match the handler's: gettid/tid on Linux, GetCurrentThreadId/thread_id on Windows, and the Mach port name (pthread_mach_thread_np/thread) on macOS. Threads that never used Sentry fall back to the main hub.
• The scope travels as a serialized Event in 16 KiB chunks plus an end message, because the reporter reads one message per call. Bad or missing JSON gives an empty event. Attachments on the scope are not carried.

Tested on Linux and macOS so far. I wont be back with my Windows machine for a week!

[sdk-maintainer-bot]

👋 Thanks for sending this our way! Before a maintainer reviews the code, we ask community contributors to align with us on the approach first — it keeps your time pointed at changes we can land.

The easiest way is to open or find a GitHub issue and discuss the approach with a maintainer there, then link that issue from this PR. If the issue is already assigned to someone else, please check in with them (or with us) before continuing — otherwise two people may end up working on the same task.

See our contributing guidelines for the full picture.