WIP: fix(tracing): finish active trace on crash

[jpnurmi]

Before this PR, an in-flight trace was silently dropped on crash. And even with a manual sentry_transaction_finish right before the crash, the crash event still floated at the trace root rather than nesting under the active span — sentry_transaction_finish clears scope->span / scope->transaction_object, so by the time the crash handler captures its event, scope-apply falls through to the stale propagation context.

This PR auto-finishes the active span/transaction on crash with status aborted, and preserves scope->span / scope->transaction_object across the finish, so the trace reaches Sentry and the crash nests under it.

Before (manual finish)	After (auto-finish)

For comparison:

• sentry-cocoa: sentry_finishAndSaveTransaction → finishForCrash
• sentry-java: UncaughtExceptionHint → forceFinish(ABORTED)

[cursor]

Iterating weak children list outside mutex risks UAF

Medium Severity

finish_children releases children_mutex before iterating the swapped-out array, but the entries are weak pointers. A concurrent sentry__span_decref on another thread can free a span between the unlock and the access in the loop, so sentry__span_incref(child) then dereferences freed memory. The swap only prevents sentry_span_finish_ts from rescanning the list, not concurrent frees. On UNIX signal contexts the mutex is intentionally a no-op via sentry__block_for_signal_handler, so even the swap itself is unsynchronized there, widening the window into a secondary crash inside the crash handler.

Additional Locations (1)

• src/sentry_tracing.c#L395-L411

 

^{Reviewed by Cursor Bugbot for commit 264a69b. Configure here.}

[cursor]

Crash handler may deadlock on children_mutex

Medium Severity

sentry__trace_finish acquires tx->children_mutex in finish_children, and sentry_span_finish_ts re-acquires it via sentry__transaction_remove_child for every closed child. If a sibling thread is mid-sentry__span_new or mid-remove and holds this mutex when the inproc backend's signal-context handler fires, the handler blocks forever inside the crash path. This turns a crash into a hang on every concurrent-tracing+crash scenario for the inproc backend, and lengthens the window where the rest of the crash pipeline (write marker, on_crash, capture event) cannot run.

Additional Locations (1)

• src/backends/sentry_backend_inproc.c#L1159-L1160

 

^{Reviewed by Cursor Bugbot for commit ba3de42. Configure here.}

[sentry]

Bug: When a crash occurs, the transaction's event ID overwrites the crash event's ID in the envelope header, causing the crash to be misidentified by the Sentry backend.
_{Severity: HIGH}

Suggested Fix

The logic for adding items to an envelope should be revised. Either ensure that the crash event's ID is preserved in the envelope header, or revert to not mixing event and transaction items in the same envelope for crash reports. One approach could be to make sentry__envelope_add_transaction conditionally set the event ID, similar to sentry__envelope_add_event.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/backends/sentry_backend_breakpad.cpp#L182-L189

Potential issue: In the `inproc` and `breakpad` backends, the crash handling logic adds
both a crash event and the active transaction to the same envelope. The
`sentry__envelope_add_transaction` function unconditionally overwrites the envelope's
`event_id` with the transaction's ID. Since the crash event is added first, its ID is
replaced. According to the Sentry envelope specification, the envelope header's
`event_id` takes precedence, which means the Sentry backend will use the transaction's
ID to identify the crash, leading to incorrect processing and routing of the crash
event.

Also affects:

• src/backends/sentry_backend_inproc.c:1192~1199

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 4 total unresolved issues (including 2 from previous reviews).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6a2e71b. Configure here.}

[cursor]

External crash reporter drops finished transaction

Medium Severity

The transaction value from sentry__trace_finish is leaked and its trace is not sent in crash handling. This occurs when an external crash reporter is launched (in inproc and breakpad backends) or when the before_send_func hook discards the crash event (in the native backend), as the transaction is not properly managed in these paths.

Additional Locations (1)

• src/backends/sentry_backend_native.c#L869-L995

 

^{Reviewed by Cursor Bugbot for commit 6a2e71b. Configure here.}

[cursor]

Session leaked when disk transport creation fails

Low Severity

The refactor moves sentry__envelope_new() and sentry__envelope_add_session(envelope, session) inside the if (disk_transport) branch. Previously the envelope wrapped the session unconditionally and was freed via sentry_envelope_free(envelope) when the disk transport could not be created, which also released the session. Now, when sentry_new_disk_transport returns null, only transaction is decref'd while session is never wrapped or freed, leaking it.

 

^{Reviewed by Cursor Bugbot for commit 6a2e71b. Configure here.}