Occasional crash on Android when entering animation

[benjidotsh]

Description

I bootstrapped a new project with React Native Reusables, which uses react-native-reanimated under the hood, and noticed that the Select component occasionally crashes when being pressed on Android.

As soon as I remove the animations, this doesn't seem to happen anymore, leading me to think it might be caused by react-native-reanimated.

Steps to reproduce

1. Press the component using animations from react-native-reanimated
2. Crash? If not, try again

Snack or a link to a repository

https://github.com/benjidotsh/react-native-reanimated-crash

Reanimated version

3.17.5

React Native version

0.78.2

Platforms

Android

JavaScript runtime

Hermes

Workflow

Expo Go

Architecture

Fabric (New Architecture)

Build type

Debug app & dev bundle

Device

Android emulator

Host machine

macOS

Device model

Medium Phone API 35

Acknowledgements

Yes

[derekvawdrey]

+1 same exact issue on new arch, old architecture worked well enough.

[nd-gorm]

+1

[Tamimjabr]

+1

[Tamimjabr]

any updates? it happens for me too

[hirbod]

Just a few more details: the crash isn’t related to React Native Reusables, but it’s definitely tied to Layout Animations.
After shipping a small animation, we instantly got 140 crash reports, so I removed it for Android via OTA.

RN 0.79.2, New Arch, Reanimated 3.17.5

RetryableMountingLayerException
Unable to find viewState for tag XXX. Surface stopped: false

[bartlomiejbloniarz]

@benjidotsh Does it reproduce consistently for you? I can't get it to crash.

It seems that it doesn't reproduce on API 36. I got the crash on API 35.

I was only able to reproduce it once. Does anyone here have a more consistent way of reproducing it?

[hirbod]

Unfortunately, I have repro'd this once during development, likely when I pressed R, so maybe the crash on production is related to OTA reloads? I really don't know. I tried hard to get a repro :/

[bartlomiejbloniarz]

I couldn't find a reliable way to reproduce this issue. But I have an idea of where it might be coming from. I am writing it down for future reference.

On iOS react-native uses a pull system, i.e. when a new tree is available, the update is pulled by the mounting manager. This always happens on the main thread. With layout animations we call pullTransaction manually. In both cases this happens on the main thread so there is no race condition between them.

But on Android the pullTransaction function can be called on the JS thread. The transaction is then scheduled to be mounted on the main thread. It might happen that:

• pullTransaction is called on the JS thread - we recognize that an entering animation should start, so we schedule startEnteringAnimation
• before pullTransaction is finished, triggerUI is called on the main thread
• triggerUI executes startEnteringAnimation, which in turn calls pullTransaction to apply the first animation frame
• the first pullTransaction has not yet been applied, as it has to wait for the main thread - so the view that we are animating has not yet been inserted into the tree
• so we are tying to apply an update to a view that doesn't exist yet.

This would explain why the getViewState function fails.

Fixing that is not necessarily easy, because we will probably have to instead insert the view with the first frame update, so that we are sure it is always present in the tree. But that introduces a weird intermediate state where react might think that the view is present at a given index, but it actually has not been inserted yet. I want to try to figure out if there is a different solution.

[benjidotsh]

For what it's worth, for me it's very reproducible and consistent. If I'd have to put a number on it, I'd probably say it crashes at least 1 out of 2 times I press it, but probably more like 3 out of 4 times.

[goatrenterguy]

Running into the same issue. Snack

[Tamimjabr]

Any updates about this?