Gate printMountItem in error handlers behind enableFabricLogs#56012
Closed
JakobFelixJulius wants to merge 2 commits intofacebook:mainfrom
Closed
Gate printMountItem in error handlers behind enableFabricLogs#56012JakobFelixJulius wants to merge 2 commits intofacebook:mainfrom
JakobFelixJulius wants to merge 2 commits intofacebook:mainfrom
Conversation
Summary: Two `printMountItem()` call sites in `MountItemDispatcher.kt` error handlers are not gated behind `enableFabricLogs()`, while all other call sites in the same file are. When a Fabric mount operation fails under memory pressure, the unguarded error handler calls `toString()` on every mount item in the batch via `String.format()`, triggering a fatal OutOfMemoryError on Android (256MB heap limit). This affects 67 users in production — 87% Android 16, all Samsung devices. ## Changelog: [Android] [Fixed] - Gate diagnostic printMountItem calls in MountItemDispatcher error handlers behind enableFabricLogs to prevent OOM crash
Re-add the "We want to mark the mount item that caused exception" comment that was inadvertently removed in the previous commit. Made-with: Cursor
|
This would be huge, I have the same OOM crashes with my Android users and it all points down to this. |
|
@alanleedev has imported this pull request. If you are a Meta employee, you can view this in D97414011. |
Collaborator
|
This pull request was successfully merged by @JakobFelixJulius in 7a546f9 When will my fix make it into a release? | How to file a pick request? |
|
@alanleedev merged this pull request in 7a546f9. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Two
printMountItem()call sites inMountItemDispatcher.kterror handlers are not gated behindReactNativeFeatureFlags.enableFabricLogs(), while every otherprintMountItemcall site in the same file is.When a Fabric mount operation fails under memory pressure, the unguarded error handler calls
toString()on every mount item in the batch — each usingString.format()— which triggers a fatalOutOfMemoryError(Android 256MB heap limit). The device is already low on memory when the original mount error occurs, so allocating diagnostic strings for the entire batch is the killing blow.Impact: 67 affected users in production, 87% Android 16, all Samsung devices.
Production stacktrace (67 occurrences)
Device: Samsung SM-S938B (Galaxy S25 Ultra), Android 16, 12GB RAM
Heap limit: 256MB, <1% free after GC
Fix:
Gate the two remaining
printMountItemcall sites behindenableFabricLogs(), matching the existing pattern used at all other call sites in the same file.Changelog:
[ANDROID] [FIXED] - Gate diagnostic
printMountItemcalls inMountItemDispatchererror handlers behindenableFabricLogs()to prevent OOM crashTest Plan:
Applied as a patch to a production app. OOM crash from the unguarded error handler path no longer occurs — confirmed over several weeks with 67 previously affected users.
The change is strictly additive gating — no logic changes. All other
printMountItemcall sites in the same file already use the sameenableFabricLogs()guard, so this just makes the two error-handler sites consistent.