Description
Rendering a <Text numberOfLines={1}> whose content contains composed character clusters (stacked combining marks, e.g. Zalgo-style user display names) crashes the app on iOS with an uncatchable NSRangeException when the truncation ellipsis boundary falls inside one of those clusters:
NSRangeException: *** -[NSConcreteTextStorage attributesAtIndex:longestEffectiveRange:inRange:]: Range or index out of bounds
(also observed as NSMutableRLEArray objectAtIndex:effectiveRange:: Out of bounds)
This is a production crash for us: any user whose friend/chat contact has such a display name gets a deterministic crash on every visit to the screen rendering it. Because the throw happens on the main thread inside Core Animation's draw pass, it is not catchable from JS and always aborts the app.
Root cause
The problem is in processTruncatedAttributedText in ReactCommon/react/renderer/textlayoutmanager/platform/ios/react/renderer/textlayoutmanager/RCTTextLayoutManager.mm (introduced for #37926, unchanged on main at time of filing):
drawAttributedString:paragraphAttributes:frame:drawHighlightPath: computes glyphRange, then calls processTruncatedAttributedText.
- When
maximumNumberOfLines > 0 and truncation is active, that method mutates the NSTextStorage (removeAttribute: / addAttribute: for foreground/background color on the truncated character range) inside enumerateLineFragmentsForGlyphRange: — mutating a text storage during its own layout manager's enumeration is unsupported by TextKit.
- Each mutation triggers attribute fixing (
fixAttributesInRange), which snaps attribute runs to composed-character-sequence boundaries. When the truncated character range starts mid-cluster, the runs shift relative to the layout manager's already-computed glyph→character mapping.
- The subsequent
drawGlyphsForGlyphRange: / the highlight pass (characterRangeForGlyphRange: + enumerateAttribute:inRange:) query the storage with stale ranges → NSRangeException → SIGABRT.
Suggested fix direction
Collect the truncated character ranges during enumerateLineFragmentsForGlyphRange: and apply the attribute edits after the enumeration (wrapped in beginEditing/endEditing); expand ranges with rangeOfComposedCharacterSequencesForRange: before mutating; and clamp with NSIntersectionRange against textStorage.length before enumerateAttribute:inRange: in the highlight pass.
Steps to reproduce
- Open the Snack on an iOS device or simulator (not web): https://snack.expo.dev/@normanwilde.equals/nsrangeexception-crash
- Scroll through the list.
- The app crashes with
NSRangeException once a row's width truncates the string mid-cluster.
The Snack renders this production-sourced display name at container widths 20→200pt in 0.5pt steps with numberOfLines={1}:
◍🥝۪〬.࠭⤿𝓚𝔀𝓜◍🥭۪〬
(22 code points / ~8 visible glyphs: combining marks — including U+20DD COMBINING ENCLOSING CIRCLE and Arabic/Meetei Mayek marks — stacked on symbol and emoji bases, plus Mathematical Script letters.)
The width sweep matters: the crash only fires at widths where the ellipsis cuts inside a composed cluster, so a single fixed width usually misses — which is why this is hard to hit in a trivial test yet deterministic in real layouts.
React Native Version
0.85.3
Affected Platforms
Runtime - iOS
Output of npx @react-native-community/cli info
System:
OS: macOS 26.5
CPU: (10) arm64 Apple M4
Memory: 215.69 MB / 16.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 22.22.2
path: ~/.nvm/versions/node/v22.22.2/bin/node
Yarn:
version: 4.7.0
path: /opt/homebrew/bin/yarn
npm:
version: 10.9.7
path: ~/.nvm/versions/node/v22.22.2/bin/npm
Watchman:
version: 2024.07.29.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.16.2
path: ~/.rbenv/shims/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 25.5
- iOS 26.5
- macOS 26.5
- tvOS 26.5
- visionOS 26.5
- watchOS 26.5
IDEs:
Xcode:
version: 26.6/17F113
path: /usr/bin/xcodebuild
Languages:
Ruby:
version: 3.3.4
npmPackages:
react:
installed: 19.2.3
wanted: 19.2.3
react-native:
installed: 0.85.3
wanted: 0.85.3
Stacktrace or Logs
NSRangeException: *** -[NSConcreteTextStorage attributesAtIndex:longestEffectiveRange:inRange:]: Range or index out of bounds
0 CoreFoundation __exceptionPreprocess
1 libobjc.A.dylib objc_exception_throw
2 UIFoundation (NSLayoutManager internals)
3 UIFoundation (NSLayoutManager internals)
4 React -[RCTTextLayoutManager drawAttributedString:paragraphAttributes:frame:drawHighlightPath:] + 616 (RCTTextLayoutManager.mm:98)
5 React -[RCTParagraphTextView drawRect:] + 548 (RCTParagraphComponentView.mm:409)
6 UIKitCore (CALayerDelegate drawLayer:inContext:)
7 UIKitCore UIGraphicsPushContext
9 QuartzCore CABackingStoreUpdate_
12 QuartzCore CA::Layer::layout_and_display_if_needed
14 QuartzCore CA::Transaction::commit()
... (main run loop / UIApplicationMain)
MANDATORY Reproducer
https://snack.expo.dev/@normanwilde.equals/nsrangeexception-crash
Screenshots and Videos
No response
Description
Rendering a
<Text numberOfLines={1}>whose content contains composed character clusters (stacked combining marks, e.g. Zalgo-style user display names) crashes the app on iOS with an uncatchable NSRangeException when the truncation ellipsis boundary falls inside one of those clusters:This is a production crash for us: any user whose friend/chat contact has such a display name gets a deterministic crash on every visit to the screen rendering it. Because the throw happens on the main thread inside Core Animation's draw pass, it is not catchable from JS and always aborts the app.
Root cause
The problem is in
processTruncatedAttributedTextinReactCommon/react/renderer/textlayoutmanager/platform/ios/react/renderer/textlayoutmanager/RCTTextLayoutManager.mm(introduced for #37926, unchanged onmainat time of filing):drawAttributedString:paragraphAttributes:frame:drawHighlightPath:computesglyphRange, then callsprocessTruncatedAttributedText.maximumNumberOfLines > 0and truncation is active, that method mutates theNSTextStorage(removeAttribute:/addAttribute:for foreground/background color on the truncated character range) insideenumerateLineFragmentsForGlyphRange:— mutating a text storage during its own layout manager's enumeration is unsupported by TextKit.fixAttributesInRange), which snaps attribute runs to composed-character-sequence boundaries. When the truncated character range starts mid-cluster, the runs shift relative to the layout manager's already-computed glyph→character mapping.drawGlyphsForGlyphRange:/ the highlight pass (characterRangeForGlyphRange:+enumerateAttribute:inRange:) query the storage with stale ranges →NSRangeException→ SIGABRT.Suggested fix direction
Collect the truncated character ranges during
enumerateLineFragmentsForGlyphRange:and apply the attribute edits after the enumeration (wrapped inbeginEditing/endEditing); expand ranges withrangeOfComposedCharacterSequencesForRange:before mutating; and clamp withNSIntersectionRangeagainsttextStorage.lengthbeforeenumerateAttribute:inRange:in the highlight pass.Steps to reproduce
NSRangeExceptiononce a row's width truncates the string mid-cluster.The Snack renders this production-sourced display name at container widths 20→200pt in 0.5pt steps with
numberOfLines={1}:◍🥝۪〬.࠭⤿𝓚𝔀𝓜◍🥭۪〬
(22 code points / ~8 visible glyphs: combining marks — including U+20DD COMBINING ENCLOSING CIRCLE and Arabic/Meetei Mayek marks — stacked on symbol and emoji bases, plus Mathematical Script letters.)
The width sweep matters: the crash only fires at widths where the ellipsis cuts inside a composed cluster, so a single fixed width usually misses — which is why this is hard to hit in a trivial test yet deterministic in real layouts.
React Native Version
0.85.3
Affected Platforms
Runtime - iOS
Output of
npx @react-native-community/cli infoStacktrace or Logs
MANDATORY Reproducer
https://snack.expo.dev/@normanwilde.equals/nsrangeexception-crash
Screenshots and Videos
No response