Race-condition crash in HybridCameraSession.start() — attach-side sibling of #3730 (iPhone 11, iOS 18.7.7, v5.0.4)

[qutrek]

What's happening?

App crashes with EXC_CRASH (SIGABRT) on iPhone 11 / iOS 18.7.7 during normal camera usage. The crashed thread is always a CoreMedia FigCaptureSessionNotificationQueue worker processing _handleConfigurationCommittedNotificationWithPayload and asserting in [AVCaptureOutput attachToFigCaptureSession:]_block_invoke.cold.1 at AVCaptureOutput.m:364. A separate thread is in HybridCameraSession.start() → AVCaptureSession.startRunning() → _buildAndRunGraph at the moment of the assert.

This is the attach-side sibling of #3730. #3730 (closed as fixed in v5.0.0) was the detach-side of the same race; the attach side appears not to have been addressed and is reproducible in v5.0.4.

We have 6 byte-for-byte identical crash reports from a single user from real TestFlight usage. All triggered by ordinary actions: photo retake, zoom switching, video record start, and general camera usage with no specific repro action reported. Each triggered through a different user-visible action but produced the same stack frames in the crashed thread and the same parallel HybridCameraSession.start() thread.

Hypothesis

HybridCameraSession.start() calls session.startRunning() immediately after a previous configure()'s commitConfiguration() returned, with no barrier waiting for CoreMedia to finish propagating the asynchronous "configuration committed" notification on FigCaptureSessionNotificationQueue. On multi-physical-cam devices (iPhone 11 has wide + ultra-wide), the CoreMedia XPC commit takes longer to propagate than on single-cam devices, widening the race window. When the notification handler runs _makeConfigurationLive: and iterates outputs to call attachToFigCaptureSession:, an output's _outputInternal->figCaptureSession is non-NULL (already attached by the racing startRunning), tripping the internal assert.

The serial Self.queue in HybridCameraSession correctly serializes JS-driven calls (configure, start, stop), but does not synchronize with CoreMedia's async commit notification.

Reproduceable Code

Standard usage. The <Camera> is mounted with stable photo/video outputs; isActive is derived from focus + foreground + a pendingMedia flag (off during a per-shot review screen).

const photoOutput = usePhotoOutput(PHOTO_OUTPUT_OPTIONS); // stable options object
const videoOutput = useVideoOutput({
  targetResolution: VIDEO_RESOLUTION,
  targetBitRate: VIDEO_BIT_RATE,
  enableAudio: !isMuted,            // mute toggle recreates the output instance
});
const outputs = useMemo(() => [photoOutput, videoOutput], [photoOutput, videoOutput]);

const constraints = useMemo<Constraint[]>(() => {
  const out: Constraint[] = [
    { fps: 60 },
    { videoStabilizationMode: 'cinematic-extended' },
  ];
  if (enablePhotoHdr) {
    out.unshift({ photoHDR: true });
    if (deviceSupportsHdrVideo) {
      out.push({ videoDynamicRange: { bitDepth: 'hdr-10-bit', colorSpace: 'hlg-bt2020', colorRange: 'full' } });
    }
  }
  return out;
}, [enablePhotoHdr, device]);

// pendingMedia toggles isActive during photo/video review (free sensor for review, restart on retake)
const isActive = visible && isFocused && isForeground && hasPermission && pendingMedia == null;

<Camera
  ref={cameraRef}
  style={StyleSheet.absoluteFill}
  isActive={isActive}
  device={device}
  outputs={outputs}
  constraints={constraints}
  mirrorMode={cameraPosition === 'front' ? 'on' : 'off'}
  orientationSource="device"
  enableLowLightBoost={enableLowLightBoost}
  enableSmoothAutoFocus={enableSmoothAutoFocus}
  enableDistortionCorrection={enableDistortionCorrection}
  onStarted={onCameraStarted}
  onError={onError}
/>

User-visible actions that trigger reconfigure → start():

• Photo capture → review → tap "Retake" (isActive flips off → on).
• Toggle mute (isMuted) — useVideoOutput's memo invalidates on enableAudio change, recreating the AVCaptureMovieFileOutput instance, which forces removeOutput/addOutputWithNoConnections in updateOutputs.
• Toggle HDR (enablePhotoHdr) — new constraints reference triggers configure().
• Flip front/back — new device.
• Zoom switching past the wide↔ultra-wide threshold (zoom itself is imperative via controller.setZoom, but iOS internally posts a configuration notification when the active sub-device changes on a multi-physical-cam logical device).

Relevant log output

Exception Type:  EXC_CRASH (SIGABRT)
Termination Reason: SIGNAL 6 Abort trap: 6

Crashed thread (CoreMedia FigCaptureSessionNotificationQueue):
0   libsystem_kernel.dylib    __pthread_kill + 8
1   libsystem_pthread.dylib   pthread_kill + 268
2   libsystem_c.dylib         __abort + 132
3   libsystem_c.dylib         abort + 136
4   libsystem_c.dylib         __assert_rtn + 284
5   AVFCapture                __45-[AVCaptureOutput attachToFigCaptureSession:]_block_invoke.cold.1 + 44 (AVCaptureOutput.m:364)
6   AVFCapture                __45-[AVCaptureOutput attachToFigCaptureSession:]_block_invoke + 100 (AVCaptureOutput.m:364)
7   libdispatch.dylib         _dispatch_client_callout + 16
8   libdispatch.dylib         _dispatch_lane_barrier_sync_invoke_and_complete + 56
9   AVFCapture                -[AVCaptureOutput attachToFigCaptureSession:] + 108 (AVCaptureOutput.m:363)
10  CoreFoundation            -[NSSet makeObjectsPerformSelector:withObject:] + 188
11  AVFCapture                -[AVCaptureSession _makeConfigurationLive:] + 344 (AVCaptureSession.m:4199)
12  AVFCapture                -[AVCaptureSession _handleConfigurationCommittedNotificationWithPayload:] + 600 (AVCaptureSession.m:5445)
13  AVFCapture                avcaptureFigCaptureSessionNotification + 176 (AVCaptureSession.m:6678)
14  CoreFoundation            __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 128
15  CoreFoundation            ___CFXRegistrationPost_block_invoke + 92
16  CoreFoundation            _CFXRegistrationPost + 436
17  CoreFoundation            _CFXNotificationPost + 736
18  CoreFoundation            CFNotificationCenterPostNotificationWithOptions + 140
19  CoreMedia                 CMNotificationCenterPostNotification + 96
20  CoreMedia                 __figXPCConnection_HandleNotificationMessage_block_invoke + 132

Parallel vision-camera thread (com.margelo.camera.session):
8   AVFCapture                -[AVCaptureSession _buildAndRunGraph:] + 1372 (AVCaptureSession.m:4709)
9   AVFCapture                -[AVCaptureSession _setRunning:] + 224 (AVCaptureSession.m:2674)
10  AVFCapture                -[AVCaptureSession startRunning] + 452 (AVCaptureSession.m:2536)
11  QutrekDev                 partial apply for closure #1 in HybridCameraSession.start() + 56
12  QutrekDev                 closure #1 in static Promise.parallel(_:_:) + 96 (Promise.swift:117)

Camera Device

{
  "id": "com.apple.avfoundation.avcapturedevice.built-in_video:0",
  "position": "back",
  "physicalDevices": ["wide-angle-camera", "ultra-wide-angle-camera"]
}

(iPhone 11 dual back camera; both back-facing sub-devices in a single logical multi-physical-cam device.)

Device

iPhone 11 (iPhone12,1), iOS 18.7.7

VisionCamera Version

5.0.4

Can you reproduce this issue in the VisionCamera Example app?

Have not tested in the example app yet. Reporting because of (a) volume of identical real-world crashes, (b) the obvious structural similarity to #3730 which suggests a known race-condition class.

Additional information

• I am using Expo
• I have enabled Frame Processors (react-native-worklets-core)
• I have read the Troubleshooting Guide
• I agree to follow this project's Code of Conduct
• I searched for similar issues in this repository and found none for the attach-side variant. Closest match is 🐛 App crashes on iPhone 17 Pro Max / iOS 26 — FigCaptureSessionSyncQueue #3730 (detach side, closed as fixed in v5.0.0).

[mrousavy]

1. Do you mount multiple Cameras?
2. I will need a reproduction repo. Without a reproduction repo I cannot help you.

[qutrek]

Thanks for the quick response.

1. Multiple Cameras — No. Verified by greping the source: only one <Camera> JSX element, only one file imports react-native-vision-camera, the modal that hosts it is mounted at most once at a time (gated by a visible prop). No frame processors either.

2. Reproduction repo — https://github.com/qutrek/vision-camera-v5-attach-race-repro

What's in it:

• A single-screen Expo app wrapping the production CameraModal from a real shipping app, copied verbatim. Five external dependencies are stubbed (clearly marked REPRO STUB in the source) — only the surrounding glue (toast, logger, i18n, navigation focus, custom video-preview module). The camera lifecycle code itself is untouched.
• Versions pinned to match the crashing build: react-native-vision-camera@^5.0.6, react-native-vision-camera-location@^5.0.6, react-native-nitro-modules@^0.35.5, expo SDK 55, RN 0.83.6.
• README has the full crash signature + reproduction steps.

The race manifests in production on iPhone 11 / iOS 18.7.7 (6 identical TestFlight crash reports collected so far, byte-for-byte identical stacks). Most reliable triggers in our app: the photo retake cycle (isActive toggles via pendingMedia), zoom presets crossing the wide↔ultra-wide threshold on the multi-physical-cam logical device, and the mute toggle (which recreates videoOutput via useVideoOutput's enableAudio memo dep, forcing removeOutput + addOutputWithNoConnections while a prior commit notification may still be in flight).

This looks like the attach-side sibling of #3730 (which addressed the detach side). The crashed-thread stack frames are the same family, just the inverse direction:

__assert_rtn
-[AVCaptureOutput attachToFigCaptureSession:]_block_invoke.cold.1   (AVCaptureOutput.m:364)
-[AVCaptureOutput attachToFigCaptureSession:]_block_invoke
_dispatch_lane_barrier_sync_invoke_and_complete
-[AVCaptureOutput attachToFigCaptureSession:]                       (AVCaptureOutput.m:363)
-[NSSet makeObjectsPerformSelector:withObject:]
-[AVCaptureSession _makeConfigurationLive:]                         (AVCaptureSession.m:4199)
-[AVCaptureSession _handleConfigurationCommittedNotificationWithPayload:]
avcaptureFigCaptureSessionNotification

…with a parallel HybridCameraSession.start() → AVCaptureSession.startRunning() → _buildAndRunGraph thread.

Could you reopen this so we can keep tracking it? Happy to add anything else you need.

[mrousavy]

Sure, thanks for the repro - we'll look into this! Maybe we need to use a single DispatchQueue instead of multiple ones for each Session, but not sure. Or call dispose or configure() in useEffect cleanup earlier

[qutrek]

Should we keep tracking under #3773 (currently closed) or would you prefer a fresh ticket? Happy to test any patch on the repro repo whenever you have something to try.

[mrousavy]

Let's keep this open sincd it has a repro