[3.7.0] Data type not recognized by value unpacker. at valueUnpacker (WorkletRuntime::WorkletRuntime:1:1477) #5660
Comments
github-actions
bot
added
the
Missing repro
|
Hey! 👋 The issue doesn't seem to contain a minimal reproduction. Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem? |
|
I don't know if this is related but while testing a PR #5216 I found that some AP initWithContext/NativeProxy I had to add a non optional parameter which is a valueUnpackerCode of type String. You may have to include this missing argument/type in some function call or provide its default value. |
|
@joe-sam thanks for the heads up, can you please be more specific? What is AP? where this code should be placed? public void initWithContext(ReactApplicationContext reactApplicationContext, String valueUnpackerCode) {
mReactApplicationContext = reactApplicationContext;
mNativeProxy = new NativeProxy(reactApplicationContext, valueUnpackerCode);
mAnimationManager.setAndroidUIScheduler(getNativeProxy().getAndroidUIScheduler());
compatibility = new ReaCompatibility(reactApplicationContext);
compatibility.registerFabricEventListener(this);
} |
|
AP was a typo I meant API interface. valueUnpackerCode is a new argument to initContext/nativeProxy. You possibly may have multiple mismatched library versions that might be trying to invoke the reanimated API from the earlier/later library interface. This code snippet comes from here . |
|
This issue is causing many crashes in my project after updating to React Native 0.73.4, Reanimated 3.7.0 and old architecture. It crashes often but not consistently so it's hard to come up with a repro but I am looking into it. Can you elaborate on the potential fix your mention with |
|
@anders-friis-topdk use version unfortunately I do not have the time to look into this at this moment, I've downgraded to 3.6.2 for the time being. edit: I used |
|
@efstathiosntonas |
|
I am on RN 0.72.10. |
|
@joe-sam did you managed to check if your prod version crash after pinning the version in |
|
Same with RN 0.73.4. Had no such problem with RN 0.72 and 3.3.0. Resolution does nothing in prod. |
|
Hey @efstathiosntonas, thanks for reporting this issue.
@joe-sam This API is private and used only internally, you should never need to make any changes to it.
@joe-sam Having multiple versions of Reanimated installed at once usually breaks things. That's why in #4914 (released in 3.6.0) we added a runtime check that asserts that only one instance of Reanimated is present: For more details, see https://docs.swmansion.com/react-native-reanimated/docs/guides/troubleshooting/#multiple-versions-of-reanimated-were-detected. We recommend the solution from #5660 (comment).
Sure, the error comes from this react-native-reanimated/src/reanimated2/valueUnpacker.ts Lines 65 to 67 in b9caec4 When copying JS values from RN runtime to UI runtime (e.g. worklet closure), they are first serialized from JS values to C++ shareables (intermediate format, runtime-agnostic data structures) and then parsed from C++ shareables to JS values.
The error in the issue description states that |
|
thanks @tomekzaw for the detailed explanation. It seems that we need to revisit our animated hooks and methods and change things around. This is not an issue with 3.6.2 so recent changes have caused this. Question is, are you going to revisit this else/if function and improve it/fix it? If not, this is breaking the API on several npm modules with reanimated as a dep since according to my bugsnag reports there are 2 npm modules that cause this crash. It's really hard to reproduce though 🤷♂️ |
|
Honestly, I'd like to eliminate
I think I will submit a PR with a small refactor. |
|
@efstathiosntonas As described above, At this point, we need to know what object caused } else {
- throw new Error('[Reanimated] Data type not recognized by value unpacker.');
+ throw new Error('[Reanimated] Data type not recognized by value unpacker.' + ' String(objectToUnpack));
} |
|
I'm having the same issue and can recreate it approx 1 in 5 times in my app by following a certain sequence. With your code amendment I'm using 3.7.0 and RN 0.73.4 This crash is happening on Android, interestingly I get a different one if I follow the same sequence on iOS. I will update that tomorrow. |
|
thanks @alexstanbury, @tomekzaw no matter how many times I try I cannot get it to crash in my environment, sorry 🫤 The part of the code where this crashes was working perfectly fine on < 3.7.0, it srarted showing up after the upgrade on my bugsnag logs. edit: this module creates the crash: https://github.com/SimformSolutionsPvtLtd/react-native-reactions |
|
@alexstanbury Can you try |
|
The current stack trace is useless as when this error/exception occurs a redundant stack trace is printed. |
|
@joe-sam Just to confirm that I understand your proposal correctly – your idea is to get the stack trace from the RN runtime when the value is serialized from JS value into a C++ intermediate form (technically, this is called This way we would at least know the origin of the values copied into the UI runtime, in terms of what functions passed them to |
|
I'll be testing & recreating this morning so if you can provide instructions on how to make the above changes, I'll give it a go. |
|
I am seeing this in production as well. RN0.73.4, Reanimated 3.7.0.
|
|
@dpyeates Thanks for letting us know! @alexstanbury Great to hear, thanks in advance! Let's start with the following change that should print more information about the failing value: } else {
- throw new Error('[Reanimated] Data type not recognized by value unpacker.');
+ throw new Error('[Reanimated] Data type not recognized by value unpacker.' + ' _toString(objectToUnpack));
} |
Happening on
This was working fine with the same above versions since 2 months i guess, |
|
@tomekzaw Yes, essentially correct (and could be hidden behind a feature flag), so as to easily create a reproducer which is only possible if we know the context of the exception. |
|
@tjzel don't know if it makes any sense but iOS is in edit: the app won't crash on simulator, just the red screen of death, the counter is keep going though on the background. simulator screenshot: Click me
|
|
Well, for me it also happens randomly. Sometimes it happens every 5 minutes and sometimes it is running for several minutes without error. In my case, I am testing it on Android, so maybe indeed Android has a higher chance to trigger error. Edit: That is correct, there is an error on the red screen with this stacktrace, but you can dismiss it and the app still works |
|
@tjzel this is also happening on IOS. in production, although it didnot print any stack trace. 
|
|
I have encountered the same stack trace. This issue manifests on my Android and iPad devices with an approximate probability of 1 in 50.Thanks to guys who are working on the issue. version: 3.7.2 |
|
me to |
|
Thanks everyone for your effort here. Thanks to reproduction postem by @Elrohil44 we managed to find the underlying problem and it's a race condition. We will soon patch this up and try to release Reanimated 3.8.0 shortly afterwards. |
Latropos
added
Repro provided
…ds (#5759) ## Summary Fixes #5660, a regression introduced in #4300. The aforementioned race condition happens this way: 1. An object using a `ShareableHandle` underneath (e.g. a shared value) is created. 2. This object is accessed on UI thread. 3. The initializer of this `ShareableHandle` get called on the UI thread. 4. At the same time, JS thread schedules an operation on this object (e.g. setting a value of shared value). 5. Access on UI thread forces the initialization. The condition of the if clause resolves to true and UI thread tries to access the runtime.  6. However, access from JS thread has locked the runtime and causes the UI runtime to wait. 7. Then, JS thread enters the same if clause body and initializes the whole shareable. 8. After initializing and releasing the runtime, UI thread gets unblocked. 9. However, now `initializer_` has been nulled and causes memory access issues. It's difficult to change the whole flow of locking to prevent such scenarios. Therefore we won't null the `initializer_` object anymore. However, this won't fix the problem of potential double initialization. Luckily, the code of `valueUnpacker` already prevents that with its shareable handle cache and the fact that runtime operations must be sequential. ## Test plan Run the following race condition reproduction made - you should re-run the app several times (probably up to 20ish) since it's most likely to happen when the app starts. It's also more likely to happen on Android simulators (at least for me). <details> <summary> Test code </summary> ```tsx import {useSharedValue} from 'react-native-reanimated'; import {useEffect, useState} from 'react'; const value = 666666; const Screen = () => { const sv = useSharedValue(value); useSharedValue(1); useSharedValue(2); useSharedValue(3); sv.value = value; useEffect(() => { // eslint-disable-next-line @typescript-eslint/no-unused-vars const currentValue = sv.value; }, [sv]); return null; }; const ReanimatedCrashReproduction = () => { const [render, setRender] = useState(false); useEffect(() => { const interval = setInterval(() => setRender(r => !r), 500); return () => clearInterval(interval); }, []); return render ? <Screen /> : null; }; export default ReanimatedCrashReproduction; ``` </summary> You can do the following to see that double initialization happens still, but all is well 🚰.  Big thanks to @piaskowyk for the debugging help 🚀
|
@tjzel thank you for fixing this 🔥 , is there an ETA for 3.8.0 😅 ? |
|
|
|
It's an absolute priority for us to ship production crash fixes asap 🚤 |
|
finally I'll get rid of 1K lines of my monkey(donkey-dog-cat)-patch of reanimated |
|
still waiting a patch for this :'( |
|
@angelica-snowit This issue was fixed with #5759 which has already been merged to main and thus should be also released as nightly on npm. Please try |
|
I downgraded to 3.6.3 but im still getting this issue. Is that expected and is it known which version is the last known good version? |
|
@tmitchel2 this started after upgrading to 3.7.0, never encountered it on 3.6.2, it shouldn't happen in 3.6.3 though since it only included some web fixes in comparison to 3.6.2 according to the release notes. Did you cleaned your project and metro cache after downgrading? |
|
@tmitchel2 Can you give a look on ur npm/yarn lock file
This can be the culprit !! |
|
I had the exact same thought and when I downgraded again I locked it down to 3.6.1, but actually looking back in git I can see it was indeed still using 3.7.1 in the lockfile (facepalm) :) |
|
3.8.0 is out, thanks @tjzel ❤️ |
|
I'm getting this error on 3.8.1 with jest. |
|
I'm still getting this in 3.8.1. |
|
I was getting this in Jest tests. I was mocking using RN 0.74.1, Expo SDK 51, Reanimated 3.10.1 |
and others
Description
Cannot reproduce it locally, for now I've encountered in production builds on Androids 11,12,13,14.
Error:
Data type not recognized by value unpacker. at valueUnpacker (WorkletRuntime::WorkletRuntime:1:1477)Full stacktrace:
Steps to reproduce
Snack or a link to a repository
no-repo-cannot-reproduce
Reanimated version
3.7.0
React Native version
0.73.4
Platforms
Android
JavaScript runtime
Hermes
Workflow
React Native
Architecture
Paper (Old Architecture)
Build type
Release app & production bundle
Device
Real device
Device model
LG G8 ThinQ™ (LM-G820), Mi Note 10, Galaxy S22 Ultra (SM-S908U), moto g(8) power
Acknowledgements
Yes
The text was updated successfully, but these errors were encountered: