Apple Silicon / arm64 / M1 compatibility?

[eugene1g]

Hi,

We're using & loving react-refresh-webpack-plugin - thank you!

Recently Apple Silicon came out with arch64-based CPUs. Somehow, this plugin breaks on that architecture with a strange error as reported at facebook/create-react-app#10090

The error looks like this on node=15.2.1 npm=7.0.10 platform=darwin arch=arm64 -

Starting the development server...


<--- Last few GCs --->

[23567:0x148008000]      705 ms: Scavenge 62.1 (89.8) -> 51.2 (89.8) MB, 1.0 / 0.0 ms  (average mu = 0.992, current mu = 0.992) allocation failure 
[23567:0x148008000]      784 ms: Scavenge 67.7 (90.0) -> 57.3 (91.7) MB, 1.2 / 0.0 ms  (average mu = 0.992, current mu = 0.992) allocation failure 


<--- JS stacktrace --->

FATAL ERROR: WasmCodeManager::Commit: Cannot make pre-reserved region writable Allocation failed - process out of memory
 1: 0x10053def4 node::Abort() [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 2: 0x10053e074 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string<std::nullptr_t>(char const*) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 3: 0x100663dd8 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 4: 0x100663d6c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 5: 0x100b00418 v8::internal::wasm::WasmCodeManager::Commit(v8::base::AddressRegion) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 6: 0x100b00008 v8::internal::wasm::WasmCodeAllocator::AllocateForCodeInRegion(v8::internal::wasm::NativeModule*, unsigned long, v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 7: 0x100b00cfc v8::internal::wasm::NativeModule::CreateEmptyJumpTableInRegion(int, v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 8: 0x100affc18 v8::internal::wasm::NativeModule::AddCodeSpace(v8::base::AddressRegion, v8::internal::wasm::WasmCodeAllocator::OptionalLock const&) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
 9: 0x100b00b18 v8::internal::wasm::NativeModule::NativeModule(v8::internal::wasm::WasmEngine*, v8::internal::wasm::WasmFeatures const&, v8::internal::VirtualMemory, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, std::__1::shared_ptr<v8::internal::Counters>, std::__1::shared_ptr<v8::internal::wasm::NativeModule>*) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
10: 0x100b02b78 v8::internal::wasm::WasmCodeManager::NewNativeModule(v8::internal::wasm::WasmEngine*, v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, unsigned long, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
11: 0x100b0f320 v8::internal::wasm::WasmEngine::NewNativeModule(v8::internal::Isolate*, v8::internal::wasm::WasmFeatures const&, std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, unsigned long) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
12: 0x100adeee0 v8::internal::wasm::AsyncCompileJob::CreateNativeModule(std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, unsigned long) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
13: 0x100adf094 v8::internal::wasm::AsyncCompileJob::GetOrCreateNativeModule(std::__1::shared_ptr<v8::internal::wasm::WasmModule const>, unsigned long) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
14: 0x100ae6ec8 v8::internal::wasm::AsyncCompileJob::PrepareAndStartCompile::RunInForeground(v8::internal::wasm::AsyncCompileJob*) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
15: 0x100ae6cf0 v8::internal::wasm::AsyncCompileJob::CompileStep::Run(v8::internal::wasm::AsyncCompileJob*, bool) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
16: 0x100ae6c00 v8::internal::wasm::AsyncCompileJob::CompileTask::RunInternal() [/opt/homebrew/Cellar/node/15.2.1/bin/node]
17: 0x100592aa0 node::PerIsolatePlatformData::RunForegroundTask(std::__1::unique_ptr<v8::Task, std::__1::default_delete<v8::Task> >) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
18: 0x100591b94 node::PerIsolatePlatformData::FlushForegroundTasksInternal() [/opt/homebrew/Cellar/node/15.2.1/bin/node]
19: 0x100c0527c uv__async_io [/opt/homebrew/Cellar/node/15.2.1/bin/node]
20: 0x100c14df0 uv__io_poll [/opt/homebrew/Cellar/node/15.2.1/bin/node]
21: 0x100c0569c uv_run [/opt/homebrew/Cellar/node/15.2.1/bin/node]
22: 0x1004a3960 node::SpinEventLoop(node::Environment*) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
23: 0x100571ef8 node::NodeMainInstance::Run(node::EnvSerializeInfo const*) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
24: 0x100518ff4 node::Start(int, char**) [/opt/homebrew/Cellar/node/15.2.1/bin/node]
25: 0x190ae8f54 start [/usr/lib/system/libdyld.dylib]

The reproduction case is simple -

npx create-react-app my-app
cd my-app
npm start # Triggers the errors
env FAST_REFRESH=false npm start   # <-- The app work

I do not use create-react-app, and use this plugin directly - but experience exactly the same failure case with webpack 4 as in that issue. If I comment out the line that adds this plugin and make no other changes, everything else works as expected.

Do you have any guesses why the plugin would fail with WASM-related errors on the Apple arch64 / M1 chip?

[idetatsu]

Same here.
The weird thing is that some of my CRA projects do work and some do not.
For me, env REACT_APP_FAST_REFRESH=false npm start did not do the trick.

[akx]

The traceback leads to https://github.com/nodejs/node/blob/bb3cbba9533b37429292fd1005efb8099e7ba872/deps/v8/src/wasm/wasm-code-manager.cc#L1609-L1617 – it looks like setting some permissions on a memory segment fails.

[pmmmwh]

This is all due to upstream - react-refresh-webpack-plugin isn't particular the one that is incompatible here, but mostly our dependencies (source-map which does use WASM, etc.) or the platform we run on (stuff like native file watchers, chokidar, etc.) Node.js have not released official builds for Darwin-ARM64 yet according to the supported platform list (Proposal here) - and to my knowledge only Node.js 15 would have support since ARM64 is only available in V8 8.6 which is only in Node.js 15 (and the HEAD of the Node repo).

I'll close this for now since there's nothing I can do unfortunately. I do not own a M1 based machine, nor does this project contain code that is non-ES-compliant JavaScript.

[pmmmwh]

However - since the error is related to memory - you can try to apply this Node.js option to limit the amount of memory Node.js would try to allocate:

--max-old-space-size=<Memory Units in MB>

[pmmmwh]

Also - nodejs/node#35986 should be a potential fix that would go out in a new release but we would have to wait a bit.

[eugene1g]

Thank you for doing the research @pmmmwh 👏

I can confirm that the Node PR you found (nodejs/node#35986) fixes this specific issue upstream, and it has been merged into the main branch as of nodejs/node@c1442ec

Now we just wait for Node to cut new releases with that commit.

[eugene1g]

@idetatsu If you use CRA, can you try env FAST_REFRESH=false npm start (without REACT_APP_ prefix as this specific env flag is not quite like the others in CRA)

[pmmmwh]

THIS HAVE BEEN FIXED IN NODEJS 15.3.0 🎉

[samturner]

For anyone else that has this issue and can't move to Node 15 (my project requires 12 at this point in time): I resolved it by uninstalling Node 12 and re-installing it under Rosetta.

[egonbraun]

Same here.
The weird thing is that some of my CRA projects do work and some do not.
For me, env REACT_APP_FAST_REFRESH=false npm start did not do the trick.

This did the trick for me with create-react-app with node lts. I use a Macbook Air M1 2020 with Bigsur.

THIS HAVE BEEN FIXED IN NODEJS 15.3.0 🎉

Not for everyone, I tried node 15.8.0 and I was having the issue as well.

[pmmmwh]

Please report to Node.js if you're having issues with arm64 builds - the issue lies in the lower level compilation and there is nothing much we can do with a pure JS library.

You can also try installing Node.js under Rosetta 2, which will slightly hinder performance but could work.

[t0guro]

After installing Node v15.9.0, it started successfully.

[maxshuty]

This is a writeup I did to explain how to get this working on an M1 chip in two minutes without the need to upgrade your node version in case anyone else finds themselves here as this is still a top Google result for the issue.

Unfortunately upgrading node isn't always an options as some apps have dependencies that require a specific version of node and upgrading them is not in the playing cards - like the frontend-maven-plugin for Java apps, for example.

[alanwhy]

One answer solved my problem very well

wasm code commit Allocation failed - process out of memory

$ nvm uninstall 14
$ arch -x86_64 zsh 
$ nvm install 14
$ nvm alias default 14

[ash-bergs]

One answer solved my problem very well

wasm code commit Allocation failed - process out of memory

$ nvm uninstall 14
$ arch -x86_64 zsh 
$ nvm install 14
$ nvm alias default 14

Node v15 here, and this worked beautifully for me 👌