EXC_BAD_ACCESS in Room.publisherShouldNegotiate / Room.fullConnectSequence on every connect (2.14.0 + 2.14.1, macOS arm64)

[utkarsh-socratic]

SDK version: client-sdk-swift 2.14.0 and 2.14.1 (both reproducible)
Platform: macOS 26.5 (Tahoe), arm64
App: menubar SwiftUI client embedding LiveKit via a thin wrapper SDK

Symptom

Every connect to a Room crashes with EXC_BAD_ACCESS within ~5–8 s of Room.connect(...). Two distinct stacks observed in the same SDK version, both deep inside Room:

Stack A — on first SDP offer

SignalClient._process(signalResponse:)
 → Room.signalClient(_:didReceiveOffer:offerId:)
 → Room.publisherShouldNegotiate(force:)
 → direct field offset for Room._regionManager
 → EXC_BAD_ACCESS (KERN_INVALID_ADDRESS at 0x28)

Stack B — during initial connect sequence

Room.fullConnectSequence(_:_:)
 → @objc closure #1 in Room.fullConnectSequence(_:_:)
 → EXC_BAD_ACCESS (KERN_INVALID_ADDRESS at 0x20)

The crashing thread in stack A is the main thread doing a SwiftUI layout pass; the corrupting work is on a webrtc dispatch thread (webrtc::Thread::ProcessMessages → PhysicalSocketServer::WaitPoll) that the Room delegate hop returns into.

Memory corruption, not a null deref

Bad-access addresses differ across reproductions: 0x28, 0x10001002a, 0x7a326d303934685d (ASCII garbage, looks like a stomped value), 0x20. Same SDK version, same call site. That pattern points at a use-after-free of a Room-owned object (likely _regionManager, which appears as a direct field offset for symbol in stack A) rather than a static null pointer.

What rules out our deployment

Reproduced identically against three independent LiveKit servers:

1. LiveKit Cloud (production environment)
2. LiveKit Cloud (staging environment)
3. Self-hosted livekit-server via the project's own dev docker-compose, fronted by a local realtime worker registering against ws://localhost:7880

Same SDK version, same call stack, same 0x28 subtype on stack A regardless of which server is on the other end. Server-side ICE/TURN/SFU is therefore not the variable.

Reproducibility

100% — five .ips files from a single afternoon, every voice session attempted ended this way. The connect path always reaches Room.publisherShouldNegotiate (stack A) or dies during fullConnectSequence (stack B); there is no successful session on this build.

Tried

• 2.14.1 → crash (stack A consistently)
• 2.14.0 → crash (stack A primarily, stack B once)
• 2.13.0 → could not test; SDK removed LiveKitSDK.setTracing(_:) and the Span(label:) initializer used by our ConnectTracing, so it does not compile against our codebase without source changes.

Happy to share .ips files privately if useful — they contain workspace IDs / user identifiers that I'd rather not paste in a public issue.

Environment

• SwiftPM, Swift 6 language mode
• LiveKit dependency surface used: Room.connect(...), ConnectOptions(enableMicrophone: true) (publish-during-join), Room.prepareConnection for prewarm, LiveKitSDK.setLogLevel, LiveKitSDK.setTracing
• Transitive: livekit-uniffi-xcframework 0.0.6, webrtc-xcframework 144.7559.6

[pblazej]

Can you share anonymized ips files? e.g. with AI @utkarsh-socratic

You can use the newest release 2.15.0.

[utkarsh-socratic]

Thanks for the quick reply, @pblazej. Updated and retested today on 2.15.0 (revision 9859018) with the rebuilt webrtc-xcframework 144.7559.8 — the crash reproduces identically.

Environment

• macOS 26.5 (build 25F71), arm64 (Mac16,7)
• Swift toolchain: ships with Xcode 26.5 / Swift 6 strict concurrency
• LiveKit Swift SDK: 2.15.0 (Package.resolved confirms revision: 9859018394f1b34e3e04ae859debce96d855e1d8)
• webrtc-xcframework: 144.7559.8 (revision: 53d268c89d242791f0771fb022fe4b423f2263d9)
• livekit-uniffi-xcframework: 0.0.6

Crash signature (unchanged from the original report)

EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS at 0x0700000000000028

Crashing thread (com.apple.root.user-initiated-qos.cooperative):
 #0  UnsafeContinuation.resume(returning:)                                  +44   [Cosmo]
 #1  _resumeUnsafeThrowingContinuation<A>(_:_:)                             +76   [Cosmo]
 #2  @objc completion handler block implementation                          +108  [Cosmo]
     for @escaping @callee_unowned @convention(block) (@unowned NSError?) -> ()
 #3  @objc closure #1 in Room.publisherShouldNegotiate(force:)              +120  [Cosmo]
 #4  partial apply for @objc closure #1 in Room.publisherShouldNegotiate    +1    [Cosmo]
 ...
 #11 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*)      +1    [libswift_Concurrency.dylib]

Loaded images at crash time include LiveKitWebRTC.framework (the new 144.7559.8 binary) and /usr/lib/swift/libswift_Concurrency.dylib.

Anonymized .ips: https://gist.github.com/utkarsh-socratic/a5a0143b00d642f1195a3b9528b33db6

The bad-access address varies across reproductions (0x28, 0x10001002a, 0x06479746972758b, 0x0700000000000028) — the bottom byte is consistently 0x28 (offset 40 into a junk pointer), the top bytes are ASCII garbage. That fingerprint is the same heap-corruption pattern @zdrohC described on #1016 — the auto-bridge resuming an UnsafeContinuation whose AsyncContext layout doesn't match what completeTaskWithClosure in the host runtime expects.

What this rules out

I had been hopeful 2.15.0 would fix this because the rebuilt webrtc-xcframework was the obvious candidate for an ABI mismatch. It didn't — which says the binary rebuild alone isn't sufficient on macOS 26.5. Possibilities:

1. The rebuilt LiveKitWebRTC.framework is still being compiled against a Swift runtime whose AsyncContext layout differs from macOS 26.5's libswift_Concurrency.dylib.
2. The bug isn't actually in the prebuilt framework's continuation layout — it's in how Room.publisherShouldNegotiate awaits one of the @objc completion-handler methods on the Swift side, and the same compile-time bridge is reproduced even after the binary swap.

@zdrohC's downstream workaround on #1016 (wrap the @objc completion calls in manual withCheckedThrowingContinuation to force the continuation to be emitted against the host runtime) would address both — and it's specifically the call sites that Room.publisherShouldNegotiate exercises that we'd need to patch.

What rules in client-side

I've confirmed the crash is independent of:

• LiveKit server: same crash against LiveKit Cloud production, LiveKit Cloud staging, and self-hosted livekit-server 1.x via the project's own dev docker-compose.livekit.yml (ws://localhost:7880). Server-side ICE/TURN/SFU/codec is not the variable.
• Cosmo's wrapper code: same crash with our connect-timeout wrapper removed (direct await Room.connect(...)), with VPIO disabled (AudioManager.shared.setVoiceProcessingEnabled(false) at app launch), with the room delegate eagerly retained, and with publish-during-join toggled off.
• LiveKit version: same crash on 2.14.0, 2.14.1, and now 2.15.0. (Couldn't test 2.13.0 — it removed LiveKitSDK.setTracing and Span(label:) which our tracing integration calls.)

It reproduces on the first SDP offer of every session, ~5–8 s after Room.connect returns control. 100% reproduction rate on this machine.

Asks

1. Could you confirm what macOS version your release-test rig is on? @zdrohC's analysis on Camera publish SIGBUS in UnsafeContinuation.resume from LKRTCCameraVideoCapturer completion on macOS 26.1 #1016 + the consistent macOS 26.x signal here suggests this is specifically a host-runtime ABI issue on 26.x that won't reproduce on 26.0 / Sonoma.
2. Would you accept a PR that applies the withCheckedThrowingContinuation wrapper from Camera publish SIGBUS in UnsafeContinuation.resume from LKRTCCameraVideoCapturer completion on macOS 26.1 #1016 to the negotiation-side completion-handler calls in Room (the ones reachable from publisherShouldNegotiate)? If yes I can put one together against main.

Happy to share the other .ips files I have from earlier today (same crash on 2.14.1 prod, 2.14.1 local Docker, etc.) if useful — they all have the same top frames.

[pblazej]

Thanks for the detailed follow-up and for putting the gist together. Before we dig
further — could you check whether the .ips may have been altered by the AI tool
used to anonymize it? A few things in the symbolicated stacks don't line up with
the 2.15.0 source or with arm64 itself, and I want to rule out the anonymization
step before drawing any conclusions:

• Several frames have unaligned image offsets (0x3e78f9, 0xcec5, various +1
  symbol locations). arm64 instructions are always 4-byte aligned, so these
  addresses can't appear in a genuine crash report.
• @objc closure #1 in Room.publisherShouldNegotiate(force:) — this symbol doesn't
  exist in the SDK. The function has no closures that get bridged to ObjC blocks.
• The call path Room.signalClient(_:didReceiveOffer:offerId:) →
  publisherShouldNegotiate from your stack A doesn't exist in the code —
  didReceiveOffer only runs the subscriber answer path and never triggers
  publisher negotiation.
• direct field offset for Room._regionManager is a data symbol (a constant), not
  code, so it can't appear as a step in a call chain — and publisherShouldNegotiate
  doesn't access _regionManager.
• Stack B's @objc closure #1 in Room.fullConnectSequence(_:_:) — that function
  contains no closures.

Because of this, the current logs unfortunately can't be used to localize the
crash. Could you share a full, unmodified .ips straight from
~/Library/Logs/DiagnosticReports? If it contains identifiers you'd rather not
post publicly, feel free to redact the strings by hand (please avoid passing it
through an LLM — that's likely what mangled this one) or send it privately and
we'll keep it off the public thread. If the frames in your report show only
offsets (e.g. Cosmo + 0x12345) rather than symbol names, please also attach the
app's dSYM, or symbolicate the report by opening it in Xcode first.

A minimal sample project that reproduces the crash would work just as well.

Happy to dig in as soon as we have a clean trace.

[pblazej]

One more thing that would really speed this up: since the crash reproduces 100% on your machine on every connect, a minimal reproducible example would be the fastest path to a fix — a bare SwiftPM executable that just calls Room.connect(...) (plus a token/URL placeholder), with the wrapper SDK, tracing, and uniffi dependencies stripped out. If the crash survives in that form, we can bisect it directly; if it doesn't, that also tells us a lot about where to look.