-
Notifications
You must be signed in to change notification settings - Fork 633
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RangeError: Maximum call stack size exceeded when require/load very big json file #135
Comments
Thanks for reporting this. It seems like we have a problem with compiling large JSON files. We are looking into it and will post an update here. Meanwhile, as a workaround can you parse as a string with JSON.parse()? |
Thanks for your reply, I'll try and let you know today. On road now. |
I just verified JSON.parse works. See https://github.com/dongyuwei/tiny_english_dictionary/blob/hermes/trie-service.js#L18, I use |
In my case I have a 14MB file which builds fine in debug mode but Hermes hangs when trying to optimize. I had to turn off hermes optimizations for the build to complete. Let me know if I can help to somehow debug this for you. |
There is a unit test to parse json: @tmikov can you modify and run the test with my big json file |
We investigated this when it was reported and we believe we understand the bug. We haven't forgotten it, and we have been workin to address it, but progress has been slow because the fix is non-trivial. There are two separate problems:
The workaround is to use I will look into escalating this, so the fix can land sooner. |
This happened to me when I upgraded my react-native https://react-native-community.github.io/upgrade-helper/?from=0.63.4&to=0.64.0
Happens both on android and ios. |
Setting inlineRequires: false in metro.config.js fixed it for me |
Is there any update on the fix? |
I have a 13mb JSON file which should be loaded locally. I tried basically everything, but it always gives me this error... Can someone help me? Any working work-around for this? Or a fix somehow? Thank you... @tmikov |
@traingethermarc the workaround is to use JSON.parse(). |
This is happening to one of the apps I'm working on (1) BUT it does not import any big JSON files. On the other hand, the other app I'm working on (2) doesn't experience this, could it be related to auth0? because my former uses auth0 but the latter does not. |
it has been two years. And this issue still occurs for the latest 0.9 version hermes. |
What's hermes' max call stack size? I'm getting max call stack size errors for recursive functions as deep as just 60 calls. |
@cristianoccazinsp For JS to JS recursion, the maximum depth is dynamic and depends on the size of every frame and the size of the register stack, which is configurable. In the default configuration, the following code performs 55,000 recursive invocations without optimization, and 87,000 with optimization:
Hermes has a separate fixed stack limit for native calls, which is set to 128. So, if you change the recursive invocation from |
Native stack errors is just the crash I'm facing right now. Sigh, 128 is so small! This used to work fine with JSC and now blows up with Hermes. Sadly, the code is for an HTML parsing library that relies on recursion so 128 will definitely cause issues as HTMLs could be huge. |
Keep in mind that the low number is only for cases involving recursion through a native function. The number is deliberately very conservative to guarantee that a native stack overflow will never occur. It is even lower in some build modes, because the native stack (which is not controlled by Hermes) can and does overflow quite easily. The limit can be increased by changing this line: hermes/include/hermes/VM/Runtime.h Line 905 in 2c66a23
There is some work in progress for obtaining and checking the actual stack size, which on most cases will result in significantly increased depth, but no promises when it will land. |
I'm not entirely sure why I get native stack depth errors even though the recursion happens entirely in JS. Does calls to |
Yes. Most "standard library" functions are implemented in C++ and unfortunately count as native. The best way to address this is to check whether the native stack is actually overflowing, instead of setting artificial hard limits. I will see if I can finish that work. |
@tmikov I replaced all |
Workaround for: facebook/hermes#135
With this comment I want to raise awareness of this issue and show that there is a high demand for it to be fixed. (Even though there is a workaround to import as string and then use |
Summary: Original Author: 4092035+mikeduminy@users.noreply.github.com Original Git: 1b759f4 As discussed in #135, the default stack size doesn't work for all use cases. In particular, when very large and complex bundles are loaded in dev mode. This PR bumps the default stack size from `64*1024` (512kB) to `128*1024` (1MB). As suggested by tmikov in this comment - #135 (comment). Pull Request resolved: #923 Original Reviewed By: tmikov Original Revision: D43630032 Reviewed By: tmikov Differential Revision: D44770995 fbshipit-source-id: 400221033e4c1e079535342331c99561f141b830
Summary: As discussed in facebook#135, the default stack size doesn't work for all use cases. In particular, when very large and complex bundles are loaded in dev mode. This PR bumps the default stack size from `64*1024` (512kB) to `128*1024` (1MB). As suggested by tmikov in this comment - facebook#135 (comment). Pull Request resolved: facebook#923 Reviewed By: tmikov Differential Revision: D43630032 Pulled By: neildhar fbshipit-source-id: 5f8cff91a5f01b6507870c61efa1ce507de67940
Hi, I'm trying to upgrade to Hermes in our RN app and I'm getting the Is the default max stack size going to be increased in RN 0.72? |
@Waltari10 the fix has landed in RN 0.71.4 and will likely be cherry picked into RN 0.70.9. It will also be in RN 0.72. |
Thanks for the info! Curiously we are already using 0.71.4 in our app though and still getting the error 🤔 |
Disclaimer: I'm not an expert. Oh I just noticed that your error message includes
Since this is a native stack issue I guess that neither JSON nor frequent bridge access is the problem. What does your stack trace look like? Have a look at the stack trace in this comment. Notice the multiple lines that say: Maybe the transpilation step of your builds is adding too many of these native calls to functions that are called in a deeply-nested way. You could see if any changes to your babel settings could fix it. Or perhaps you need to hunt down what changed in your codebase from when it was working. |
I am also getting this error in Android (iOS working fine), this happened suddenly. inlineRequires: false => is already added in file Any solution? |
Hi, Been struck by this issue too when migrating from RN 0.69 to 0.70.9 and enabling hermes in the process. Would this limitation of the call stack on Line 3276 in d1be3ff
Line 296 in 081b8ac
We are essentially using AJV for JSON validation, and that library is using recursion within the Also noted that hermes/lib/VM/JSLib/Function.cpp Line 211 in d1be3ff
|
FWIW, this has been addressed in the next version of Hermes, but unfortunately we do not yet have a timeline for release or for backporting. |
Hi @tmikov, Would you mind helping me to clarify some things I'm a bit confused about? I just got hit by the This seems to be different from the original issue of this thread that was fixed in #135 (comment) In any case, my issue is that I'm using a library that needs to do recursive work where it uses apply/call functions multiple times. It works fine if I use JavaScriptCore as the engine, I did a rough test in the stack limit seems to be around ~2738 when using JSC. Is there a way to increase the limit when using Hermes or any other workaround? Here is a repo with issue: https://github.com/vmalvaro/hermes-range-error Thanks! |
@vmalvaro the limit can be increased by changing Hermes as described in this comment. |
@tmikov thanks for the quick response, I'm a bit of a newbie with Hermes so I'd appreciate your guidance. This #135 means that I have to do that change in hermes/include/hermes/VM/Runtime.h, then a custom build of Hermes + react native from source as described here https://hermesengine.dev/docs/react-native-integration? |
@vmalvaro
Those instructions are unfortunately no longer accurate for newer versions of RN, which have changed how Hermes is consumed. If you're on an RN version that is 0.69+, you can set an environment variable to point RN to the source directory where you want it to get Hermes from. See https://github.com/facebook/react-native/blob/fd9e295befcd8781190ec26a6a2fc4ef39fb1c15/packages/react-native/ReactAndroid/hermes-engine/build.gradle#L42. |
Get this issue when disabling js DEV mode System:
OS: macOS 13.4
CPU: (12) arm64 Apple M2 Pro
Binaries:
Node: 20.0.0 - /opt/homebrew/bin/node
Yarn: 1.22.19 - /opt/homebrew/bin/yarn
npm: 9.6.4 - /opt/homebrew/bin/npm
Watchman: 2023.05.01.00 - /opt/homebrew/bin/watchman
SDKs:
iOS SDK:
Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
Android SDK:
API Levels: 31, 33
Build Tools: 30.0.2, 30.0.3, 31.0.0, 33.0.0, 33.0.2
System Images: android-33 | Google APIs ARM 64 v8a
IDEs:
Android Studio: Flamingo 2022.2.1 Patch 1 Flamingo 2022.2.1 Patch 1
Xcode: 14.3/14E222b - /usr/bin/xcodebuild
npmPackages:
react: 18.2.0 => 18.2.0
react-native: 0.71.8 => 0.71.8 |
@Villar74 is your problem related to loading JSON, which is the topic of this specific issue? If not, and you believe there is a bug in Hermes, please create a new issue, preferably with more details, including source reproducing the problem. It is almost impossible to diagnose a problem from a screenshot of a stack trace of a compiled bundle. |
Finally, this long standing problem has been fixed in 3213794 and should be available in the next release of RN. |
Summary: Now that the general case is fast, and generates much better code in debug mode, stop emitting `AllocObjectLiteral` for object literals in IRGen. This allows us to compile large JSON files with reasonable performance and output in both release and debug builds. Closes #135 Reviewed By: tmikov Differential Revision: D47724425 fbshipit-source-id: 903eec6828043828965f8afa8e751ead67470d14
Hey tmikov could you please send this update in the coming patch as I needed this issue to be resolved in our codebase |
@Yashtoddle I don't understand what you mean. Send what where? |
Sorry for not explaining the stuff clearly @tmikov actually we are using Hermes in our project as the engine and now we are facing the maximum call stack size exceded error in the android app and this error is now being resolved it would be great if you send 3213794 |
@Yashtoddle we don't really control which changes are picked into each patch releases. You also need to be more specific about the version where you want this. In any case I think you can request a pick here: https://github.com/reactwg/react-native-releases/discussions . This is not a trivial bugfix, it is several commits including 18aa617 . @neildhar @cortinico what is the feasibility of picking this? |
@Yashtoddle this will be included in the upcoming RN 0.73. The feasibility of picking this fix into an earlier release will likely depend heavily on which RN version you are currently on. |
Summary: Original Author: neildhar@meta.com Original Git: bbe7966 Now that the general case is fast, and generates much better code in debug mode, stop emitting `AllocObjectLiteral` for object literals in IRGen. This allows us to compile large JSON files with reasonable performance and output in both release and debug builds. Closes facebook#135 Original Reviewed By: tmikov Original Revision: D47724425 Differential Revision: D50460149
https://github.com/dongyuwei/tiny_english_dictionary/blob/hermes/trie-service.js#L2
const words = require('./words_with_frequency_and_translation_and_ipa.json');
will throw error:The json file size is 21M, while its data structure is very simple.
Steps to reproduce the bug:
Tested with yarn 1.17.3 and nodejs 12.12.0 on Mac 10.14.5.
The text was updated successfully, but these errors were encountered: