react / react/react-native

[iOS] Prebuilt React-Core Release artifacts are built with NSAssertions enabled — RCTAssert failures become fatal NSRangeException crashes in production

未关闭
#57,454 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

Needs: Attention Needs: Repro
主要语言
C++
星标
127k
派生
25.3k
平均合并
1 天 23 小时
30 天内合并 PR
4

描述

Description

The prebuilt React Native Core Release artifacts published to Maven Central are built without NS_BLOCK_ASSERTIONS, so every RCTAssert in the framework is compiled in and live in production apps. When React Native is built from source, the standard Release configuration (ENABLE_NS_ASSERTIONS = NO) strips these asserts, so they are no-ops in production.

This has two consequences:

  1. Assert conditions that are benign in a source Release build become fatal in a prebuilt Release build. Example: in RCTViewComponentView unmountChildComponentView:index:, the index parameter is used only inside RCTAssert. With asserts stripped, a stale/mismatched index is harmless — the method just calls removeFromSuperview on the correct child. With asserts live, the same situation crashes the app.

  2. The crash is worse than an assertion failure. The assert at RCTViewComponentView.mm (v0.85.3, L154–L177) eagerly evaluates its message arguments, including [[self.currentContainerView.subviews objectAtIndex:index] tag]. When the assert condition fails because index is out of bounds, formatting the message itself throws NSRangeException — the app dies while trying to report the assert.

We hit this in production: the first release of our app on prebuilt React Native Core (RN 0.85.3) started crashing with NSRangeException in unmountChildComponentView:index: on a screen that structurally remounts children of a legacy interop view (react-native-linear-gradient 2.8.3) inside an animation loop. Our previous release (RN 0.83.9, built from source) had zero crashes on the identical screen code. iOS only, observed on iOS 18 and iOS 26.

Steps to reproduce

No app is needed — the defect is verifiable directly on the published artifacts:

# RN 0.85.3 release artifact
curl -sL https://repo1.maven.org/maven2/com/facebook/react/react-native-artifacts/0.85.3/react-native-artifacts-0.85.3-reactnative-core-release.tar.gz | tar -xz
strings React.xcframework/ios-arm64/React.framework/React | grep "Attempt to unmount"

Output (these strings only exist in the binary if the RCTAssert call sites were compiled in):

Attempt to unmount a view which is mounted inside different view. (parent: %@, child: %@, index: %@)
Attempt to unmount a view which has a different index. (parent: %@, child: %@, index: %@, actual index: %@, tag at index: %@)

The same check on the 0.86.0 release artifact (react-native-artifacts-0.86.0-reactnative-core-release.tar.gz) shows the same result, so the current stable is equally affected.

For comparison, a source-built Release archive of the same RN version does not contain these strings (asserts stripped by ENABLE_NS_ASSERTIONS = NO).

Production stack trace

NSRangeException: *** -[__NSSingleObjectArrayI objectAtIndex:]: index 1 beyond bounds [0 .. 0]
  CoreFoundation   __exceptionPreprocess
  libobjc.A        objc_exception_throw
  CoreFoundation   -[__NSSingleObjectArrayI objectAtIndex:]
  React            -[RCTViewComponentView unmountChildComponentView:index:]
  React            -[RCTMountingManager performTransaction:] (block)
  React            facebook::react::TelemetryController::pullTransaction
  React            -[RCTMountingManager performTransaction:]
  React            -[RCTMountingManager initiateTransaction:]
  libdispatch      _dispatch_main_queue_drain
  ...

Additional observation

Reproducing the same UI flow on a source-built Debug binary (where assertions are also enabled) does not trip the assert, while the prebuilt binary does. We have not isolated why, but it suggests the prebuilt binary may also differ behaviorally from a source build of the same version (build-time flags?). The primary, easily verifiable defect remains the assertions in the Release artifact.

Workaround

RCT_USE_PREBUILT_RNCORE=0 (build React Native Core from source). Verified: the crash disappears and Release builds strip the asserts as before.

Suggested fix

  1. Build the -release prebuilt artifacts with ENABLE_NS_ASSERTIONS = NO / NS_BLOCK_ASSERTIONS defined, matching what a source Release build produces.
  2. Independently: make the assert message at RCTViewComponentView.mm bounds-safe (it currently indexes out of bounds while formatting the message for the exact condition it is asserting against).

React Native Version

0.85.3 (artifact defect also verified on 0.86.0)

Affected Platforms

Runtime: iOS. New Architecture (Fabric).

Output of npx react-native info

System:
  OS: macOS 26.5.1
  CPU: (12) arm64 Apple M2 Pro
Binaries:
  Node: 24.14.0
  Yarn: 4.16.0
  npm: 11.9.0
  Watchman: 2025.06.30.00
SDKs:
  iOS SDK: 26.5
Xcode: 26.6/17F113
Ruby: 3.3.10
react-native: 0.85.3
Hermes: enabled
New Architecture: enabled

Reproducer

Not applicable — the defect is in the published build artifacts themselves; the shell commands under "Steps to reproduce" demonstrate it without an app.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从 RCTViewComponentView.mm 和 release-artifact 构建配置开始;将已发布的 0.85.3 或 0.86.0 archive 与从源代码构建的 Release archive 进行比较。运行 issue 中的 curl、tar 和 strings 命令以验证 assertion 符号,然后确认 release artifact 不再包含这些符号,并且 assert 消息不会索引到 subviews 边界之外。

由索引模型根据 Issue 内容生成。

评估

技术栈
ios, objective-c, react-native
领域
build-system, mobile
Issue 类型
缺陷
难度
4/5
预计耗时
3-5 天
活跃度
冷清
描述清晰度
基本清楚
新手友好度
52/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。