[$250] [Sentry: APP-8MH / APP-8Y9] HybridApp iOS EXC_BAD_ACCESS in YAPLLogManager log sync

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-8MH
https://expensify.sentry.io/issues/APP-8Y9

Impact (snapshot at filing)

• APP-8MH — Users (total): 375 | Events: 392 | Users (last 7d): 34 | Events (last 7d): 34
• APP-8Y9 — Users (total): 230 | Events: 251 | Users (last 7d): 31 | Events (last 7d): 32
• First seen: 2026-03-01 (APP-8Y9), 2026-03-12 (APP-8MH)
• Last seen: 2026-07-02 (ongoing)
• Platform: iOS HybridApp
• App version(s): 9.3.59 through 9.4.23
• Affected route(s): unknown (background log sync during image resize)
• Mechanism: mach (EXC_BAD_ACCESS)

Stack trace (top frames, first-party only)

yaplImageResize handleWithArguments block
YAPLLogManager logWithLevel / commitLogLine
LogSyncerManager.addLog
_ArrayBuffer._consumeAndCreateNew (APP-8MH)
objc_release (APP-8Y9)

Suspected cause

Use-after-free or race in YAPLLogManager / LogSyncerManager when logging from a background queue during yaplImageResize. Not related to FullStory (despite APP-8MH appearing in closed #91291 body).

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Sibling Sentry IDs: APP-8MH, APP-8Y9
• Prior GH issues: [Due for payment 2026-06-12] [$250] [Sentry: APP-8Z0 / APP-8PM] HybridApp iOS EXC_BAD_ACCESS in FullStory native onSessionStarted  #91291 (closed — FullStory cluster; different root cause)
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

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

[lorretheboy]

Proposal

What is the root cause of that problem?

Both Sentry issues are the same data race in the OldDot native logging pipeline, which lives in the Mobile-Expensify submodule (not in App itself — App only pins the submodule commit):

App/contributingGuides/philosophies/HYBRID-APP.md

Line 21 in a9e6aed

- 📂 [**app**](https://github.com/Expensify/Mobile-Expensify/tree/main/app): Expensify Classic JavaScript logic (aka YAPL)

Causal chain: the yaplImageResize YAPL handler does its resize work on a background dispatch queue and logs from its completion block → YAPLLogManager logWithLevel: / commitLogLine run on that caller's queue → LogSyncerManager.addLog appends the line to its in-memory Swift Array buffer with no synchronization → at the same time another thread (main-thread logging, or the periodic sync that drains the buffer) is also appending to / consuming the same array. Swift Array is not thread-safe: two concurrent mutations race on the buffer's reference count and reallocation, so one thread ends up working on a buffer the other already freed. That is exactly the two crash signatures — EXC_BAD_ACCESS inside _ArrayBuffer._consumeAndCreateNew (append reallocating a freed buffer, APP-8MH) and inside objc_release (over-release of an element during the racing copy, APP-8Y9). They're one bug with two timings, which is why the versions and mechanism match.

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

Fix it in Mobile-Expensify at the single convergence point, LogSyncerManager: make its log buffer accessible only through one serial context, so append and drain can never overlap. Concretely, give the manager a private serial DispatchQueue and route both addLog and the sync/drain path through it:

private let logQueue = DispatchQueue(label: "com.expensify.logSyncer")

func addLog(_ line: LogLine) {
    logQueue.async { self.buffer.append(line) }
}
// drain for sync: logQueue.sync { let batch = buffer; buffer.removeAll(); return batch }

Fixing it there (rather than in yaplImageResize) covers every logging call site at once — any YAPL handler that logs off the main thread hits the same buffer. Once merged, App picks it up via the routine Mobile-Expensify submodule bump.

What alternative solutions did you explore? (Optional)

Making YAPLLogManager commitLogLine hop onto a dedicated serial logging queue before calling the syncer would also fix these two crashes, but it only protects callers that go through YAPLLogManager — anything calling LogSyncerManager.addLog directly would still race, so guarding the buffer itself is the safer level. An os_unfair_lock/NSLock around the buffer instead of a queue is equivalent; the serial queue keeps logging non-blocking for callers.

[melvin-bot]

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

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

This is a native memory-safety crash inside the OldDot (Mobile-Expensify) YAPL logging pipeline, not the New Expensify (App) repo — App only pins the submodule commit:

App/contributingGuides/philosophies/HYBRID-APP.md

Line 21 in a9e6aed

- 📂 [**app**](https://github.com/Expensify/Mobile-Expensify/tree/main/app): Expensify Classic JavaScript logic (aka YAPL)

None of the crashing symbols exist in the App repo (confirmed — no YAPLLogManager / LogSyncerManager / yaplImageResize), so the whole EXC_BAD_ACCESS (mach, use-after-free) stack is OldDot:

yaplImageResize handleWithArguments block
YAPLLogManager logWithLevel / commitLogLine
LogSyncerManager.addLog
_ArrayBuffer._consumeAndCreateNew   (APP-8MH)
objc_release                        (APP-8Y9)

Read straight off those frames, it's a data race: the yaplImageResize handler runs its resize on a background worker queue and logs from that block → YAPLLogManager commitLogLine → LogSyncerManager.addLog appends to its in-memory Swift Array buffer with no synchronization. Meanwhile another thread — main-thread logging, or the periodic sync that drains the buffer — appends to / consumes the same array. Swift Array is not thread-safe, so two concurrent mutations race on the buffer's reference count and its copy-on-write reallocation, and one thread keeps operating on storage the other already freed.

That's why the two sibling clusters share versions and the mach mechanism — one bug, two timings:

• APP-8MH — EXC_BAD_ACCESS in _ArrayBuffer._consumeAndCreateNew: an append reallocates a buffer the racing thread already released.
• APP-8Y9 — EXC_BAD_ACCESS in objc_release: an element is over-released while a racing copy-on-write copy is in flight.

It's low-frequency and reproduction-unknown precisely because it needs concurrent logging during a background image resize. The interleaving that produces both signatures:

sequenceDiagram
    participant Main as Main thread (logging)
    participant Bg as Background queue (yaplImageResize)
    participant Buf as LogSyncerManager buffer (Swift Array, unsynchronised)

    Note over Main,Bg: no serialisation — both threads own the same COW storage
    Bg->>Buf: addLog() -> buffer.append(line)
    Main->>Buf: addLog() -> buffer.append(line)
    Note over Buf: concurrent append triggers COW realloc + release on shared storage
    Buf-->>Bg: EXC_BAD_ACCESS in _ArrayBuffer._consumeAndCreateNew  (APP-8MH)
    Buf-->>Main: EXC_BAD_ACCESS in objc_release  (APP-8Y9)

Loading

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

Fix it in Mobile-Expensify at the single convergence point — LogSyncerManager — so the buffer is only ever touched from one serial context and an append can never overlap a drain. Give the manager a private serial DispatchQueue and route both the append and the sync/drain through it, draining with copy-then-clear so the network send happens outside the critical section:

private let logQueue = DispatchQueue(label: "com.expensify.logSyncer")

func addLog(_ line: LogLine) {
    logQueue.async { self.buffer.append(line) }   // non-blocking for callers; FIFO preserves log order
}

func drainLogs() -> [LogLine] {
    logQueue.sync {
        let batch = buffer
        buffer.removeAll()
        return batch
    }
}

The sync path calls drainLogs() and sends batch without holding the queue — the old buffer is atomically detached before anything consumes/releases it, which removes both the use-after-free on _ArrayBuffer._consumeAndCreateNew and the over-objc_release. With every touch of buffer funnelled through one serial context, the two racing paths above can no longer overlap:

sequenceDiagram
    participant Main as Main thread
    participant Bg as Background queue (yaplImageResize)
    participant Q as logQueue (serial)
    participant Buf as buffer
    participant Net as Sync/network

    Bg->>Q: addLog() async
    Main->>Q: addLog() async
    Q->>Buf: append (serialised, FIFO — never overlaps)
    Net->>Q: drainLogs() sync
    Q->>Buf: batch = buffer; buffer.removeAll()
    Q-->>Net: return batch
    Net->>Net: send batch (outside the critical section)

Loading

Fixing it here rather than inside yaplImageResize covers every logging call site at once — any YAPL handler that logs off the main thread converges on this same buffer. App then picks the fix up through the routine Mobile-Expensify submodule bump.

To scope and validate it, use the Sentry events plus Thread Sanitizer on a debug build exercising yaplImageResize with concurrent logging to confirm the racing queues and verify the serialization removes the crash.

What alternative solutions did you explore? (Optional)

• Make LogSyncerManager an actor (or move the buffer behind an actor). This is the idiomatic Swift-concurrency version of the same fix and the compiler enforces the isolation, so no future call site can reintroduce the race. I listed it as the alternative rather than the primary because it forces addLog/drainLogs to become async and ripples out to every call site — a larger, riskier change than the drop-in serial queue.
• An os_unfair_lock / NSLock (or @synchronized) around the buffer is functionally equivalent; I prefer the queue because addLog stays non-blocking for the resize/background caller instead of contending on a lock.
• Suppressing logging inside the yaplImageResize background block avoids one concurrent path, but leaves the LogSyncerManager buffer thread-unsafe for every other background logger — it hides one caller instead of fixing the class of crash.