[Due for payment 2026-09-28] [Sentry: APP-KDN] iOS HybridApp native crash — RCTBlobManager slices a blob past its data length

[mountiny]

Sentry

• https://expensify.sentry.io/issues/APP-KDN — NSRangeException: -[NSConcreteMutableData subdataWithRange:]: range {0, 321} exceeds data length 318

Impact (snapshot at filing, 2026-09-10)

Sentry ID	Users (last 14d)	Users (total since first seen)	Events	First seen
APP-KDN	5	6	19	2026-08-25

• Last seen: 2026-09-10 (ongoing)
• Platform: iOS HybridApp (com.expensify.expensifylite)
• App version(s): 9.4.68-1, 9.4.70-0, 9.4.71-0, 9.4.72-0, 9.4.73-2, 9.4.75-0 — present on every recent build
• Mechanism: nsexception, level fatal — this is a hard native crash, not a caught error
• Thread: crashes on a _dispatch_workloop_worker_thread, off the main thread
• session.uptime_bucket: 0-30s on the sampled event, so it fires early in the session
• Device on the sampled event: iPhone 12 mini, iOS 16.7, lowMemoryThreat: true

Error

NSRangeException: *** -[NSConcreteMutableData subdataWithRange:]: range {0, 321} exceeds data length 318

Stack trace (top frames)

__exceptionPreprocess
objc_exception_throw
-[NSData(NSData) subdataWithRange:]
-[RCTBlobManager resolve:offset:size:] (RCTBlobManager.mm:115)
-[RCTBlobManager resolve:] (RCTBlobManager.mm:101)
-[RCTBlobManager createFromParts:withId:] (RCTBlobManager.mm:199)
facebook::react::ObjCTurboModule::performVoidMethodInvocation (RCTTurboModule.mm:461)
_dispatch_call_block_and_release

Suspected cause

RCTBlobManager stores blob data in a dictionary keyed by blob ID and slices it on demand. resolve:offset:size: calls subdataWithRange: using the offset and size recorded in the blob descriptor, without checking them against the length of the data actually held.

The numbers in the message say the descriptor and the stored data disagree by 3 bytes: the JS side asks for 321 bytes but only 318 are present. Two plausible sources:

1. The stored NSMutableData was truncated or partially written, so the recorded size is stale.
2. A byte-length versus character-length mismatch when a string is turned into a blob — a multi-byte UTF-8 sequence counted as characters would produce exactly this kind of small shortfall.

createFromParts:withId: is on the stack, so the crash happens while assembling a multi-part blob, which is what new Blob([...]) and FormData uploads go through. The most likely trigger in App is an attachment or receipt upload.

Because this is an NSRangeException on a background dispatch queue, there is no JS frame to catch it and the app terminates.

Reproduction

Unknown as an exact click path — 19 events across 6 users, so it is timing or content dependent rather than a deterministic screen. Starting points:

1. On iOS HybridApp, upload a receipt or attachment shortly after launch, while the app is still hydrating.
2. Try content that is not plain ASCII — a file name or text part containing multi-byte UTF-8 characters.
3. Watch for the crash under memory pressure; the sampled event had lowMemoryThreat: true.

Once reproduced, the fix is to clamp the range in resolve:offset:size: against the real data length and log rather than throw when the descriptor disagrees. That belongs upstream in react-native, so the immediate options are a patch file or a version bump once fixed upstream.

Related

• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[MelvinBot]

Proposal

What is the root cause of that problem?

RCTBlobManager trusts the blob descriptor that JS sends it and slices the stored NSData without ever range-checking it.

RCTBlobManager.mm:104-118 guards only against a missing blob. If the blob exists, line 115 calls subdataWithRange: with the JS-supplied offset/size and no comparison against data.length. Here the descriptor said 321 bytes, the dictionary held 318, and NSData raised NSRangeException.

The descriptor and the stored bytes can legitimately disagree, because nothing reconciles them:

• JS computes size on its own in BlobManager.js:87-97 (global.unescape(encodeURI(part)).length for string parts), then hands native the parts separately.
• Native assembles them in createFromParts:withId: and adds no bytes at all when a part fails: a blob part that can't be resolved returns nil at line 199, and a string whose dataUsingEncoding:NSUTF8StringEncoding returns nil does the same at line 202. Both are silent — no log, no error.

So an earlier new Blob([...]) produced a blob recorded as 321 bytes but stored as 318. The crash happens later, when that short blob is used as a part of another blob: the stack frames map exactly to line 199 → line 101 → line 115.

This is iOS-only for a concrete reason: Android's BlobModule.kt:183-198 uses Arrays.copyOfRange, which zero-pads when the requested end is past the array. Same desync, no crash. And because createFromParts runs on a _dispatch_workloop_worker_thread with no JS frame on the stack, the NSRangeException is unrecoverable.

Evidence, and what I could not confirm

Confirmed: upstream main still has the unguarded subdataWithRange: — this is not fixed in a later react-native version, so a version bump will not help.

Not confirmed: the exact 3-byte shortfall. Sentry gives 19 events across 6 users with no reproduction path, and the descriptor/data desync is created at blob creation time while the crash surfaces at consumption time, so the crashing stack cannot name the culprit. Candidate sources I considered:

1. A string part where the JS UTF-8 byte count disagrees with [NSString dataUsingEncoding:] — for example a JS→NSString conversion that mangles an astral character. A 3-byte gap is the size of one UTF-8 BMP character or one U+FFFD.
2. A nested blob part that had already been released, contributing 0 bytes.
3. Blob.js slice() does not handle a negative start: it does offset += start; size -= start, producing a negative offset and an oversized size. Ruled out for this event — the crash reports offset 0.

I deliberately did not try to pin this down further, because the fix below does not depend on which one it is, and adding a log makes the next occurrence self-diagnosing.

On the App side: nothing in src/ calls new Blob([blob]) on a native path — DownloadUtils.ts:82 is reached only through the web index.ts. The new Blob([...]) calls are most likely coming from whatwg-fetch's Response.blob(), which react-native's fetch uses. That means this cannot be fixed in App JS.

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

Add a patch-package patch for react-native and send the same change upstream. App already patches this exact module — see react-native+0.86.0+030+fix-nil-BlobModule-crash-APP-8BM.patch — so this follows an established pattern.

Two changes in RCTBlobManager.mm:

1. In resolve:offset:size:, clamp the range to the data that is actually there. Return nil for a nonsensical offset, and otherwise slice at most data.length - offset bytes, matching Android's forgiving behaviour. This turns a hard crash into a short read.
2. Report the desync instead of swallowing it. In createFromParts:withId:, and in the clamp above, call RCTLogError when a part resolves to nil or when the requested size exceeds what is stored, including the blob ID and both lengths. Right now the mismatch is invisible until it kills the app; this is what will let us find the real producer.

Add the matching entry to patches/react-native/details.md and link the upstream PR there.

What alternative solutions did you explore? (Optional)

• Bump react-native. Does not work — upstream main is still unguarded.
• Fix the producer in App JS. No native App code path creates these blobs, so there is nothing to fix at that layer.
• Fix the JS size computation in BlobManager.js. Would address one possible source, but native would still crash on every other desync, and we do not yet know which source this is. The native clamp is the change that actually stops the crash.

Related

• Parent tracker [Tracking] Top Sentry crashes monthly check-in #91302 is already linked. No other open issue covers this crash — the only other NSRangeException hit, [$250] [Sentry: APP-7CX] HybridApp iOS Fatal App Hang in YAPLJS callFunction during onBarButtonItemSelected (still occurring after #86334 closed) #91229, is an unrelated app hang.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100843) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · view recording

[mountiny]

@daledah can you review the proposla from melvin and open this to community if not good enough? thanks

[daledah]

I will look into this issue early next week

[daledah]

Thanks @MelvinBot. The clamp is the right instinct and I want it in the fix, but the proposal has three factual errors and stops one layer short of the real cause. I reproduced this deterministically on an iOS simulator (RN 0.86.0, New Arch), so we no longer have to guess at the producer.

Root cause

RCTTurboModule.mm:113 converts every JSI string argument with:

return [NSString stringWithUTF8String:value.utf8(runtime).c_str()];

value.utf8(runtime) knows its own length, but .c_str() throws that away, so stringWithUTF8String: re-derives it with strlen and stops at the first NUL byte. Meanwhile BlobManager.js counts the whole string. Descriptor and stored bytes then disagree by exactly "the NUL plus everything after it".

Measured on device - all cases built to the same JS byte count of 318, so the only variable is what native stored:

String	descriptor	native stored	desync
A×318	318	318	0
A×315 + \0 + BC	318	315	3
A×317 + \0	318	317	1
\0 + A×317	318	0	318
A×316/315/314 + é / 中 / 😀	318	318	0

desync equals the byte count from the NUL onward, exactly. This disproves suspected cause 2 in the issue body - multi-byte UTF-8 round-trips fine, emoji included. A NUL does not, and a NUL followed by two characters gives exactly the 3-byte APP-KDN shortfall.

I read the true stored length without tripping the range check by resolving a {offset: 0, size: -1} descriptor (which skips subdataWithRange: entirely) and base64-measuring it via readAsDataURL.

Feeding that 3-byte-short blob into new File([blob], 'receipt.jpg') then crashes, on queue com.meta.react.turbomodulemanager.queue:

-[RCTBlobManager resolve:offset:size:] + 400
-[RCTBlobManager resolve:] + 552
-[RCTBlobManager createFromParts:withId:] + 540
facebook::react::ObjCTurboModule::performVoidMethodInvocation(...)
_dispatch_workloop_worker_thread

Same frames as APP-KDN.

The fix

Layer 1 - the actual cause:

std::string utf8 = value.utf8(runtime);
return [[NSString alloc] initWithBytes:utf8.data() length:utf8.size() encoding:NSUTF8StringEncoding];

Preserves embedded NULs and drops a strlen from a hot path. Broad change - every TurboModule string argument on iOS - so it needs a careful upstream PR and a blast-radius note, but truncating user data at a NUL is a bug, not a contract.

Layer 2 - defence in depth, so any future desync degrades instead of killing the app:

const NSInteger length = (NSInteger)data.length;
if (offset < 0 || offset > length) {
  RCTLogWarn(@"[BlobManager] blob %@: offset %ld out of bounds for %ld stored bytes",
             blobId, (long)offset, (long)length);
  return nil;
}
const NSInteger available = length - offset;
if (size < 0 || size > available) {
  if (size > available) {
    RCTLogWarn(@"[BlobManager] blob %@: asked for %ld bytes at offset %ld, only %ld stored; truncating",
               blobId, (long)size, (long)offset, (long)available);
  }
  size = available;
}
if (offset != 0 || size != length) {
  data = [data subdataWithRange:NSMakeRange((NSUInteger)offset, (NSUInteger)size)];
}

size < 0 preserves the existing "-1 means the whole blob" contract. Add a nil guard with a log in createFromParts:withId: too, where a failed part currently contributes 0 bytes with no signal.

Use RCTLogWarn, not RCTLogError - this runs on a background queue and RCTLogError red-boxes on every occurrence in dev. For Sentry visibility, route it like patch 038.

Trade-off the proposal doesn't state: layer 2 alone converts this crash into silent data loss - with a leading NUL, a 0-byte attachment that uploads as if it succeeded (measured above, not hypothetical). That's why layer 1 is needed.

Still open: what puts a NUL into an App string in production. Best lead is whatwg-fetch's Response.blob() doing new Blob([this._bodyText]) - binary content read as text would carry NULs. Doesn't block the fix.

Next steps

Both patches go in patches/react-native/, with entries in details.md linking the upstream PRs.

@MelvinBot implement this

[MelvinBot]

Implemented both layers exactly as specified. Draft PR: #101062

What's in it — two patches in patches/react-native/, both documented in details.md:

• react-native+0.86.0+042+fix-jsi-string-truncated-at-nul-APP-KDN.patch — convertJSIStringToNSString now builds the NSString with initWithBytes:length:encoding: from the byte length the jsi::String already knows, instead of letting stringWithUTF8String: re-derive it with strlen and stop at the first NUL.
• react-native+0.86.0+043+clamp-blob-range-APP-KDN.patch — your clamp, verbatim, in resolve:offset:size:, with size < 0 preserving the "-1 means the whole blob" contract, plus nil guards with logs in createFromParts:withId: for both the unresolvable-blob-part and the unencodable-string-part cases. RCTLogWarn throughout, and #import <React/RCTLog.h> added since RCTBlobManager.mm didn't pull it in transitively.

What I verified

• ./scripts/validatePatches.sh passes.
• patch-package applies the full react-native sequence 001–043 cleanly against RN 0.86.0, with 042 and 043 applying last. I generated the patches by hand (this environment has no network for patch-package --append), so I round-tripped them through git apply -R / git apply first and then confirmed through patch-package itself — the path that actually runs on npm install.
• npm run lint-changed and npm run spell-changed are no-ops here; nothing outside patches/ changed.

I did not run an App test pass. These are iOS native patches — nothing in them is reachable from a web or Android build, so a smoke test there would be evidence about something else. Verification needs an iOS build, and I left the Tests and QA sections for you.

Two things to decide before this ships

1. Sentry routing. I used RCTLogWarn, as you specified. I did not wire it to Sentry: patch 038's mechanism is ReactSoftExceptionLogger, which is Android-only, and I have not confirmed that a native RCTLogWarn reaches Sentry on iOS in a production build. consoleIntegration is enabled in src/setup/telemetry/setupSentry.ts:37-43, but the native→JS log forwarding path is what I couldn't confirm, so I'd rather flag it than claim it works. If you want guaranteed visibility, that needs a separate call on the mechanism.
2. Upstream PRs. Neither patch has one yet. Both details.md entries say so explicitly rather than carrying a 🛑 with no context — patch 042 in particular changes the conversion for every TurboModule string argument on iOS, and the entry carries the blast-radius note for upstream review.

---

Next Steps: Mark #101062 "Ready for review" once you've filled in the Tests and QA sections, or reply with @MelvinBot <feedback> to change the implementation.