[$250] [Sentry: APP-8Z0 / APP-8PM] HybridApp iOS EXC_BAD_ACCESS in FullStory native onSessionStarted

[mountiny]

Sentry

Two Sentry groupings for the same crash:

• https://expensify.sentry.io/issues/APP-8Z0
• https://expensify.sentry.io/issues/APP-8PM

Impact (snapshot at filing, combined across both Sentry IDs)

• Users (total since first seen): ~4,625 (APP-8Z0: 612 / APP-8PM: 4,013)
• Events: ~4,712 (APP-8Z0: 614 / APP-8PM: 4,098)
• Users (last 14d): ~74 (APP-8Z0: 44 / APP-8PM: 30)
• First seen: 2026-03-27
• Last seen: now (ongoing)
• Platform: iOS, hybrid_app
• App version(s): seen on 9.3.63 through 9.3.77
• OS: iOS 26.x dominant; high-end devices (iPhone17, iPhone18)
• Mechanism: mach, fatal

Stack trace (native, top frames)

main thread (UIApplicationMain)
  -> _CFRunLoop / _dispatch_main_queue_drain
  -> PopulateInclusiveFramesForLayer
  -> readSelectorMatch
  -> -[FullStory fullstoryDidStartSession:]
  -> -[NativeFullStorySpecBase emitOnSessionStarted:]
  -> std::__1::function<T>::operator()
  -> std::__1::__hash_table<T>::__emplace_unique_key_args<T>
KERN_INVALID_ADDRESS  (EXC_BAD_ACCESS)

Suspected cause

Memory access violation inside the FullStory iOS SDK when emitting the session-started event. The crash is fully below our app surface (no first-party frames in the stack), so the underlying fix likely belongs in a FullStory iOS SDK upgrade.

Investigation suggestions

• Check what FullStory iOS SDK version we're currently shipping vs the latest release; look for fixes in the changelog around onSessionStarted / fullstoryDidStartSession.
• Group by os.version and device.class in Sentry to see if it correlates with iOS 26.x specifically.
• As a short-term mitigation, evaluate gating FullStory init on the affected OS / device subset once identified.

Reproduction

Unknown deterministically — fires on any session that reaches FullStory's onSessionStarted callback path. Sentry events are reproducible against the linked sessions in Fullstory dashboard (not pasted here to keep this issue free of identifying data — follow the link in each Sentry event).

Related

• Sibling Sentry IDs covered by this issue: APP-8Z0, APP-8PM
• Long tail of related single/few-user FullStory native variants: APP-8MH, APP-A78, APP-A35, APP-8WH, APP-9JE (all likely subsumed by the same SDK fix)
• Prior GH issues: none found

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057428000347458847
• Upwork Job ID: 2057428000347458847
• Last Price Increase: 2026-05-21

Issue Owner

Current Issue Owner: @fabioh8010

[MelvinBot]

Proposal

What is the root cause of that problem?

The crash occurs in the FullStory native iOS SDK (v1.68.3) during the session-start callback. When FullStory starts a session, fullstoryDidStartSession calls emitOnSessionStarted (a codegen-generated TurboModule EventEmitter method under New Architecture). Inside that emitter, std::__1::__hash_table::__emplace_unique_key_args hits KERN_INVALID_ADDRESS — a use-after-free or uninitialized memory access in the event emitter's internal data structure.

The app has New Architecture enabled (Podfile:82), and the emitOnSessionStarted path is only compiled under RCT_NEW_ARCH_ENABLED. The native iOS SDK v1.68.3 is 3 minor versions behind the latest (1.70.1), and FullStory's release notes for v1.70.0 list two directly relevant fixes:

• "Fixed a rare crash that could occur when starting a session"
• "Fixed a rare crash associated with objc_retain"

Both match the crash signature (EXC_BAD_ACCESS during session start, memory access violation).

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

Upgrade the FullStory native iOS SDK from 1.68.3 to 1.70.1 in ios/Podfile:

- pod 'FullStory', :http => 'https://ios-releases.fullstory.com/fullstory-1.68.3-xcframework.tar.gz'
+ pod 'FullStory', :http => 'https://ios-releases.fullstory.com/fullstory-1.70.1-xcframework.tar.gz'

Then re-run pod install to update Podfile.lock.

What alternative solutions did you explore? (Optional)

1. Wrapping emitOnSessionStarted in a try/catch or dispatch to main queue — this would require patching @fullstory/react-native source. The crash is inside FullStory's own native code, so an SDK upgrade is the cleaner path.
2. Gating FullStory init on affected iOS versions — would reduce crash rate but leave the underlying bug in place and degrade FullStory coverage.

Investigation details

Data flow to crash:

1. App starts → FullStory native module sets FS.delegate = self during init
2. FullstoryInitHandler mounts → calls consentAndIdentify() → FullStory.restart()
3. FullStory SDK starts a session → fires fullstoryDidStartSession delegate callback
4. Callback calls emitOnSessionStarted (New Arch EventEmitter codegen) outside the @synchronized block
5. CRASH: __hash_table::__emplace_unique_key_args → KERN_INVALID_ADDRESS

Key files:

• ios/Podfile:126 — native SDK version pin
• package.json:93 — @fullstory/react-native v1.9.0 (latest, no upgrade needed)
• src/libs/Fullstory/index.native.ts — init/consent flow
• src/FullstoryInitHandler.tsx — triggers FS.init()

Impact context: ~4,625 users affected (74 in last 14 days), iOS 26.x dominant, ongoing since 2026-03-27.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

Hybrid iOS builds can crash on the main thread when FullStory starts a native recording session. The crash is affecting production users and the Sentry stack is inside FullStory's session-start callback / React Native session-start event path.

What is the root cause of that problem?

App pins the FullStory native iOS SDK directly in ios/Podfile to https://ios-releases.fullstory.com/fullstory-1.68.3-xcframework.tar.gz, and ios/Podfile.lock confirms the shipped pod is FullStory (1.68.3). Newer FullStory iOS xcframework releases are already available publicly up through 1.70.1, but the app will keep shipping 1.68.3 until that URL and lockfile are updated.

On native, FullstoryInitHandler calls FS.init(userMetadata), which reaches FullStory.restart() once production metadata is available. That is the same session-start path shown in Sentry. Since the crash stack is below our JS/App code in FullStory's native callback dispatch, App-side try/catch or null checks around FS.init will not catch it; we need to move the native FullStory binary off the affected build.

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

Update the iOS FullStory pod to the latest available FullStory xcframework release. Concretely, change the direct FullStory pod URL in ios/Podfile from fullstory-1.68.3-xcframework.tar.gz to the latest available release, currently fullstory-1.70.1-xcframework.tar.gz, then regenerate ios/Podfile.lock so the pod version, checkout URL, checksum, and lock metadata all match the new binary. Keep @fullstory/react-native at 1.9.0 unless FullStory publishes a newer React Native wrapper, because npm currently reports 1.9.0 as the latest wrapper version.

If Sentry still shows the same crash after the SDK bump, add a temporary native-only guard in src/libs/Fullstory/index.native.ts / shouldInitializeFullstory to skip FullStory.restart() for the affected iOS version/device cohort while FullStory investigates. That should be treated as a fallback mitigation, not the primary fix, because it disables recording for a subset of users.

Scope boundaries:

• Files touched: ios/Podfile - pod 'FullStory' URL; ios/Podfile.lock - regenerated FullStory pod version/source/checksum entries.
• Optional fallback only if the SDK bump does not clear Sentry: src/libs/Fullstory/index.native.ts / src/libs/Fullstory/common.ts - native FullStory initialization gate before FullStory.restart().
• Platforms: iOS native / HybridApp only.
• Code paths not touched: web FullStory (src/libs/Fullstory/index.ts), Android FullStory Gradle plugin, unrelated telemetry integrations, backend/API contracts.
• API contracts or backend behavior changes: no.

What alternative solutions did you explore? (Optional)

Only wrapping FS.init, FullStory.restart(), or getSessionURL() in additional JS error handling would not address this crash because the fatal fault occurs later inside the native FullStory SDK callback path. Permanently disabling FullStory on iOS would stop the crash, but it is broader than needed and loses session replay for all iOS users; it should only be used as a short-term cohort-specific mitigation if the SDK upgrade is not sufficient.