[$250] [Sentry: APP-7WP] HybridApp iOS EXC_BAD_ACCESS in SentryFramesTracker

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-7WP

Impact (snapshot at filing)

• Users (total since first seen): 92
• Events: 101
• Users (last 7d): 18
• Events (last 7d): 18
• First seen: 2026-03-18
• Last seen: 2026-07-02 (ongoing)
• Platform: iOS HybridApp
• App version(s): 9.4.23
• Affected route(s): navigation (ttid-navigation span active)
• Mechanism: mach (EXC_BAD_ACCESS)

Stack trace (top frames, first-party only)

SentryFramesTracker.displayLinkCallback
SentryFramesTracker.reportNewFrame
RNSentryFramesTrackerListener framesTrackerHasNewFrame
RNSentryTimeToDisplay putTimeToInitialDisplayForActiveSpan
NSString stringByAppendingString

Suspected cause

EXC_BAD_ACCESS in Sentry RN SDK frames tracker during time-to-display measurement on navigation, possibly a use-after-free when appending span identifiers.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Sibling Sentry IDs (if any): none
• Prior GH issues: none
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072671248041218479
• Upwork Job ID: 2072671248041218479
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @Krishna2323

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The app enables Sentry React Navigation time-to-initial-display measurement in the shared navigation integration. That integration is included in the native Sentry setup and then registered with the root NavigationContainer, so HybridApp iOS navigation activates the Sentry RN native TTID frame tracker shown in the crash stack (RNSentryTimeToDisplay, RNSentryFramesTrackerListener, SentryFramesTracker).

App/src/libs/telemetry/integrations/common.ts

Lines 9 to 11 in a9e6aed

	const navigationIntegration = Sentry.reactNavigationIntegration({
	enableTimeToInitialDisplay: true,
	});

App/src/setup/telemetry/setupSentry.ts

Lines 11 to 25 in a9e6aed

	const integrations = [navigationIntegration, tracingIntegration, browserProfilingIntegration, breadcrumbsIntegration, consoleIntegration, reportingObserverIntegration].filter(
	(integration): integration is NonNullable<typeof integration> => integration !== undefined,
	);
	Sentry.init({
	dsn: CONFIG.SENTRY_DSN,
	// In development, debugTransport replaces the default Sentry transport.
	// When "Send data to Sentry" toggle is ON, it forwards envelopes to Sentry via fetch.
	// When the toggle is OFF, it silently discards envelopes (returns 200 noop).
	// When "Log Sentry to console" toggle is ON, it logs envelope contents to the console.
	transport: isDevelopment() ? makeDebugTransport : undefined,
	tracesSampleRate: 1.0,
	enableAutoPerformanceTracing: true,
	enableUserInteractionTracing: true,
	integrations,

App/src/libs/Navigation/NavigationRoot.tsx

Lines 261 to 266 in a9e6aed

	const onReadyWithSentry = useCallback(() => {
	endSpan(CONST.TELEMETRY.SPAN_NAVIGATION_ROOT_READY);
	endSpan(CONST.TELEMETRY.SPAN_BOOTSPLASH.NAVIGATION);
	onReady();
	navigationIntegration.registerNavigationContainer(navigationRef);
	setupNavigationFocusReturn();

The app is pinned to @sentry/react-native / RNSentry 8.2.0 and native iOS Sentry 9.5.1, so this App-side option is opting that SDK into the exact native frame-tracker path that is crashing during iOS navigation.

App/package.json

Line 130 in a9e6aed

"@sentry/react-native": "8.2.0",

App/ios/Podfile.lock

Lines 4077 to 4104 in a9e6aed

	- RNSentry (8.2.0):
	- boost
	- DoubleConversion
	- fast_float
	- fmt
	- glog
	- hermes-engine
	- RCT-Folly
	- RCT-Folly/Fabric
	- RCTRequired
	- RCTTypeSafety
	- React-Core
	- React-debug
	- React-Fabric
	- React-featureflags
	- React-graphics
	- React-hermes
	- React-ImageManager
	- React-jsi
	- React-NativeModulesApple
	- React-RCTFabric
	- React-renderercss
	- React-rendererdebug
	- React-utils
	- ReactCodegen
	- ReactCommon/turbomodule/bridging
	- ReactCommon/turbomodule/core
	- Sentry (= 9.5.1)

What changes do you think we should make in order to solve the problem?

Disable Sentry navigation time-to-initial-display measurement on native iOS while keeping navigation tracing itself enabled. The smallest App-side fix is to split the integration setup by platform: keep enableTimeToInitialDisplay: true for web if we still want that signal there, but export a native navigationIntegration with enableTimeToInitialDisplay: false or with the native TTID option omitted/defaulted off. setupSentry() should still include the navigation and native tracing integrations, and NavigationRoot should still register the navigation container; only the native TTID frame-tracker path should stop.

App/src/libs/telemetry/integrations/index.ts

Lines 1 to 12 in a9e6aed

	import * as Sentry from '@sentry/react-native';
	import {breadcrumbsIntegration, browserProfilingIntegration, consoleIntegration, navigationIntegration, shouldCreateSpanForRequest} from './common';
	const tracingIntegration = Sentry.reactNativeTracingIntegration({
	shouldCreateSpanForRequest,
	});
	// The Reporting API is a browser-only feature, so there is no native integration. This stub keeps
	// the web/native export shape in parity; it is filtered out of the integrations list on native.
	const reportingObserverIntegration = undefined;
	export {navigationIntegration, tracingIntegration, browserProfilingIntegration, breadcrumbsIntegration, consoleIntegration, reportingObserverIntegration};

App/src/libs/telemetry/integrations/index.web.ts

Lines 1 to 21 in a9e6aed

	import * as SentryReact from '@sentry/react';
	import {breadcrumbsIntegration, browserProfilingIntegration, consoleIntegration, navigationIntegration, shouldCreateSpanForRequest} from './common';
	/**
	* Browser tracing integration is enabled on Web to support web health measurements
	* such as INP, LCP, FCP, CLS.
	*/
	const tracingIntegration = SentryReact.browserTracingIntegration({
	shouldCreateSpanForRequest,
	});
	/**
	* Reporting API integration (web only). Captures browser-emitted `crash` and `intervention`
	* reports (e.g. out-of-memory interventions) that never surface as JS exceptions, giving us an
	* early signal for browser-level crashes. See https://w3c.github.io/reporting/
	*/
	const reportingObserverIntegration = SentryReact.reportingObserverIntegration({
	types: ['crash', 'intervention'],
	});
	export {navigationIntegration, tracingIntegration, browserProfilingIntegration, breadcrumbsIntegration, consoleIntegration, reportingObserverIntegration};

App/src/setup/telemetry/setupSentry.ts

Lines 11 to 25 in a9e6aed

	const integrations = [navigationIntegration, tracingIntegration, browserProfilingIntegration, breadcrumbsIntegration, consoleIntegration, reportingObserverIntegration].filter(
	(integration): integration is NonNullable<typeof integration> => integration !== undefined,
	);
	Sentry.init({
	dsn: CONFIG.SENTRY_DSN,
	// In development, debugTransport replaces the default Sentry transport.
	// When "Send data to Sentry" toggle is ON, it forwards envelopes to Sentry via fetch.
	// When the toggle is OFF, it silently discards envelopes (returns 200 noop).
	// When "Log Sentry to console" toggle is ON, it logs envelope contents to the console.
	transport: isDevelopment() ? makeDebugTransport : undefined,
	tracesSampleRate: 1.0,
	enableAutoPerformanceTracing: true,
	enableUserInteractionTracing: true,
	integrations,

Test coverage: Add or update a telemetry integration test that asserts the native integration does not enable TTID while the web integration keeps the intended web setup. Manually validate on iOS HybridApp by navigating between screens, confirming Sentry still receives navigation transactions/breadcrumbs, and confirming no new RNSentryTimeToDisplay / SentryFramesTracker crashes are reported.

What alternative solutions did you explore? (Optional)

Upgrading @sentry/react-native may also contain an upstream fix, but it is a broader JS dependency and native pod change. Disabling only native TTID is the narrower mitigation because the crash is in that measurement path, not in route tracing generally.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Krishna2323 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022072671248041218479

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On iOS HybridApp (v9.4.23), users experience an EXC_BAD_ACCESS crash in Sentry's SentryFramesTracker.displayLinkCallback → RNSentryTimeToDisplay putTimeToInitialDisplayForActiveSpan → NSString stringByAppendingString. 92 users and 101 events have been affected since 2026-03-18, still ongoing. Expected behavior: navigation should complete without a native crash while telemetry is being recorded.

What is the root cause of that problem?

navigationIntegration is configured with enableTimeToInitialDisplay: true at src/libs/telemetry/integrations/common.ts:10, and this integration is registered on native via src/setup/telemetry/setupSentry.ts:11. Under HybridApp, navigation is bridged with OldDot: the active navigation span that the native RNSentryTimeToDisplay module keeps a reference to can be ended/deallocated before the SentryFramesTracker display-link callback fires and calls putTimeToInitialDisplayForActiveSpan, which then dereferences a freed span identifier inside stringByAppendingString. The crash is only reachable when TTID tracking is enabled; disabling it on HybridApp closes the use-after-free window until the upstream @sentry/react-native 8.2.0 fix lands.

What changes do you think we should make in order to solve the problem?

1. src/libs/telemetry/integrations/common.ts:9-11 — Stop hard-coding enableTimeToInitialDisplay: true. Make it conditional: pass enableTimeToInitialDisplay: !CONFIG.IS_HYBRID_APP (import CONFIG from @src/CONFIG) so HybridApp iOS builds do not register the crashing native TTID hook while standalone builds keep the telemetry.
2. src/setup/telemetry/setupSentry.ts:49 — We already tag builds with BUILD_TYPE_HYBRID_APP; confirm the tag remains so Sentry can filter/verify the crash rate drops for HybridApp after the change.
3. Bump @sentry/react-native (currently 8.2.0 in package.json:130) to the latest 8.x that includes the upstream RNSentryTimeToDisplay null/lifetime guard for the active span (tracked in getsentry/sentry-react-native), and re-enable TTID once upgraded.
4. Add a Sentry issue-owner note referencing [Tracking] Top Sentry crashes monthly check-in #91302 so this stays gated behind the HybridApp flag until the SDK upgrade is verified in a staged rollout.

What alternative solutions did you explore? (Optional)

Disable TTID globally (regressing performance visibility on standalone) or gate at the native RNSentry layer via a patch-package — both broader than needed.

[trasnake87]

Proposal

What is the root cause of that problem?

The crash is a threading data-race use-after-free inside @sentry/react-native 8.2.0's iOS native module — not an App-level configuration mistake that a flag can safely paper over.

RNSentryTimeToDisplay.m stores the active span as a static __strong global:

static NSString *activeSpanId;

+ (void)setActiveSpanId:(NSString *)spanId {
    activeSpanId = spanId;   // JS thread
}

+ (void)putTimeToInitialDisplayForActiveSpan:(NSNumber *)value {
    if (activeSpanId != nil) {                                          // read #1
        NSString *prefixed =
            [@"ttid-navigation-" stringByAppendingString:activeSpanId]; // read #2  ← crash
        ...
    }
}

setActiveSpanId: is exported as a synchronous bridge method (RCT_EXPORT_SYNCHRONOUS_TYPED_METHOD, RNSentry.mm:953), so it executes on the JS thread. putTimeToInitialDisplayForActiveSpan: is called from the CADisplayLink frames-tracker callback (SentryFramesTracker.displayLinkCallback → RNSentryFramesTrackerListener.framesTrackerHasNewFrame → RNSentry.mm:275-276), which fires on the main run loop.

The method reads activeSpanId twice without capturing a local strong reference. When a new navigation calls setActiveSpanId: on the JS thread between the != nil guard (read #1) and stringByAppendingString: (read #2), ARC releases the old string. If its retain count reaches zero in that window, read #2 dereferences freed memory → EXC_BAD_ACCESS in NSString stringByAppendingString — exactly the top frame in the Sentry report. ARC only guarantees thread-safe retain/release for __weak accesses and local variables; concurrent mutation of a __strong global is explicitly undefined behavior under ARC.

Why intermittent and HybridApp-specific: the race requires the main-thread display-link callback for one navigation to be mid-flight at the same instant the JS thread promotes a new span. HybridApp's OldDot↔NewDot transitions generate far more rapid navigation span churn than standalone NewDot, dramatically widening the window — 101 events concentrated on HybridApp iOS since 2026-03-18 confirm this. A reliable reproducer: rapidly bounce between OldDot and NewDot screens so a new TTID span starts while the previous display-link frame is still emitting.

What changes do you think we should make in order to solve the problem?

Fix the race at its source with patch-package. The repo already patches this package (patches/sentry-react-native/@sentry+react-native+8.2.0.patch), so the workflow exists. Add to that patch:

+ (void)setActiveSpanId:(NSString *)spanId {
    @synchronized(self) {
        activeSpanId = [spanId copy];
    }
}

+ (void)putTimeToInitialDisplayForActiveSpan:(NSNumber *)value {
    NSString *spanId;
    @synchronized(self) {
        spanId = activeSpanId;  // capture strong local — survives concurrent setActiveSpanId:
    }
    if (spanId != nil) {
        NSString *prefixed = [@"ttid-navigation-" stringByAppendingString:spanId];
        [self putTimeToDisplayFor:prefixed value:value];
    }
}

The local spanId variable retains the string for the full duration of the append; a concurrent setActiveSpanId: call can no longer deallocate it mid-read. Extend the same @synchronized(self) guard to putTimeToDisplayFor: / popTimeToDisplayFor: mutations of screenIdToRenderDuration and screenIdAge, which are equally reachable from the cross-thread emit block. Update patches/sentry-react-native/details.md with the issue link, and remove the patch when we upgrade past an SDK version that upstreams this fix.

What alternative solutions did you explore? (Optional)

Making enableTimeToInitialDisplay conditional on !CONFIG.IS_HYBRID_APP avoids the crash path but permanently discards TTID telemetry for HybridApp — the signal that #91302 was expressly tracking — to hide a race we can actually eliminate. Rejected: it treats the symptom while leaving the defect in place for any future path that re-enables the flag.