Snarkjs fail beacuse eached heap limit Allocation failed - JavaScript heap out of memory

[readygo67]

When I generate a circom, JavaScript heap out of memory happens, how to fix this problem?

Written successfully: ./bls_signature_test.r1cs
Written successfully: ./bls_signature_test.sym
Written successfully: ./bls_signature_test_cpp/bls_signature_test.cpp and ./bls_signature_test_cpp/bls_signature_test.dat
Written successfully: ./bls_signature_test_cpp/main.cpp, circom.hpp, calcwit.hpp, calcwit.cpp, fr.hpp, fr.cpp, fr.asm and Makefile
Written successfully: ./bls_signature_test_js/bls_signature_test.wasm
Everything went okay, circom safe
----- Generate .zkey file -----
[INFO]  snarkJS: Reading r1cs
[INFO]  snarkJS: Reading tauG1
[INFO]  snarkJS: Reading tauG2
[INFO]  snarkJS: Reading alphatauG1
[INFO]  snarkJS: Reading betatauG1

<--- Last few GCs --->

[7649:0x150008000]    21677 ms: Mark-Compact (reduce) 4043.6 (4143.6) -> 4041.4 (4143.9) MB, 1931.75 / 0.00 ms  (average mu = 0.407, current mu = 0.231) allocation failure; scavenge might not succeed
[7649:0x150008000]    23499 ms: Mark-Compact (reduce) 4042.9 (4143.9) -> 4042.1 (4144.1) MB, 1817.83 / 0.00 ms  (average mu = 0.228, current mu = 0.002) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0x1028a9860 node::Abort() [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 2: 0x1028aacbc node::ModifyCodeGenerationFromStrings(v8::Local<v8::Context>, v8::Local<v8::Value>, bool) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 3: 0x102a11140 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 4: 0x102a110ec v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 5: 0x102b9b814 v8::internal::Heap::CallGCPrologueCallbacks(v8::GCType, v8::GCCallbackFlags, v8::internal::GCTracer::Scope::ScopeId) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 6: 0x102b9a538 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 7: 0x102b922fc v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 8: 0x102b92a78 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
 9: 0x102b7b918 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
10: 0x102e8ac48 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
11: 0x1026e8c44 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/opt/homebrew/Cellar/node/20.4.0/bin/node]
12: 0x10276b0b0 Builtins_CreateTypedArray [/opt/homebrew/Cellar/node/20.4.0/bin/node]
13: 0x1027720d0 Builtins_TypedArrayPrototypeSlice [/opt/homebrew/Cellar/node/20.4.0/bin/node]
14: 0x10a1697a0
15: 0x10a149ff0
16: 0x1026603e4 Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/20.4.0/bin/node]
17: 0x102697210 Builtins_AsyncFunctionAwaitResolveClosure [/opt/homebrew/Cellar/node/20.4.0/bin/node]
18: 0x102744fb8 Builtins_PromiseFulfillReactionJob [/opt/homebrew/Cellar/node/20.4.0/bin/node]
19: 0x102686b94 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/20.4.0/bin/node]
20: 0x10265e3f4 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/20.4.0/bin/node]
21: 0x102b27970 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
22: 0x102b27e04 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
23: 0x102b4923c v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
24: 0x102b49070 v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
25: 0x1027d8b40 node::InternalCallbackScope::Close() [/opt/homebrew/Cellar/node/20.4.0/bin/node]
26: 0x1028a4c3c node::fs::FSReqPromise<node::AliasedBufferBase<double, v8::Float64Array>>::Resolve(v8::Local<v8::Value>) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
27: 0x1028b2a64 node::fs::AfterInteger(uv_fs_s*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
28: 0x1028a3cc8 node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
29: 0x105463360 uv__work_done [/opt/homebrew/Cellar/libuv/1.46.0/lib/libuv.1.dylib]
30: 0x105466994 uv__async_io [/opt/homebrew/Cellar/libuv/1.46.0/lib/libuv.1.dylib]
31: 0x105476294 uv__io_poll [/opt/homebrew/Cellar/libuv/1.46.0/lib/libuv.1.dylib]
32: 0x105466e28 uv_run [/opt/homebrew/Cellar/libuv/1.46.0/lib/libuv.1.dylib]
33: 0x1027d9994 node::SpinEventLoopInternal(node::Environment*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
34: 0x1028ec8d4 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
35: 0x1028ec630 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node/20.4.0/bin/node]
36: 0x1028732f4 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResultImpl const*) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
37: 0x1028734dc node::Start(int, char**) [/opt/homebrew/Cellar/node/20.4.0/bin/node]
38: 0x18c18ff28 start [/usr/lib/dyld]

[leonardovona]

I have a similar problem. I'm running snarkjs on a linux x64 machine with 256GB RAM and I have a circuit composed by ~28M constraints.
I tried to increase the JavaScript heap size to 200GB by adding the node option --max-old-space-size=204800.
That solved the issue of JavaScript heap out of memory, but then, when the command snarkjs zkey new is processing the constraints from the .r1cs file, it always fails while processing constraint 10-11M, throwing a std::bad_alloc exception.
I'm using Node.js version 18.17.0, but I also tried with other versions and the problem is still there.
It doesn't seem an out of memory related issue because, when it fails, the process is using ~40GB of memory.

Output

node --max-old-space-size=204800 node_modules/.bin/snarkjs zkey new build/my_step.r1cs resources/powersOfTau28_hez_final_25.ptau build/my_step_p1.zkey
[INFO]  snarkJS: Reading r1cs
[INFO]  snarkJS: Reading tauG1
[INFO]  snarkJS: Reading tauG2
[INFO]  snarkJS: Reading alphatauG1
[INFO]  snarkJS: Reading betatauG1
processing constraints: 0/28173676
processing constraints: 100000/28173676
processing constraints: 200000/28173676
processing constraints: 300000/28173676
processing constraints: 400000/28173676
processing constraints: 500000/28173676
processing constraints: 600000/28173676
processing constraints: 700000/28173676
processing constraints: 800000/28173676
processing constraints: 900000/28173676
processing constraints: 1000000/28173676
processing constraints: 1100000/28173676
processing constraints: 1200000/28173676
processing constraints: 1300000/28173676
processing constraints: 1400000/28173676
processing constraints: 1500000/28173676
processing constraints: 1600000/28173676
processing constraints: 1700000/28173676
processing constraints: 1800000/28173676
processing constraints: 1900000/28173676
processing constraints: 2000000/28173676
processing constraints: 2100000/28173676
processing constraints: 2200000/28173676
processing constraints: 2300000/28173676
processing constraints: 2400000/28173676
processing constraints: 2500000/28173676
processing constraints: 2600000/28173676
processing constraints: 2700000/28173676
processing constraints: 2800000/28173676
processing constraints: 2900000/28173676
processing constraints: 3000000/28173676
processing constraints: 3100000/28173676
processing constraints: 3200000/28173676
processing constraints: 3300000/28173676
processing constraints: 3400000/28173676
processing constraints: 3500000/28173676
processing constraints: 3600000/28173676
processing constraints: 3700000/28173676
processing constraints: 3800000/28173676
processing constraints: 3900000/28173676
processing constraints: 4000000/28173676
processing constraints: 4100000/28173676
processing constraints: 4200000/28173676
processing constraints: 4300000/28173676
processing constraints: 4400000/28173676
processing constraints: 4500000/28173676
processing constraints: 4600000/28173676
processing constraints: 4700000/28173676
processing constraints: 4800000/28173676
processing constraints: 4900000/28173676
processing constraints: 5000000/28173676
processing constraints: 5100000/28173676
processing constraints: 5200000/28173676
processing constraints: 5300000/28173676
processing constraints: 5400000/28173676
processing constraints: 5500000/28173676
processing constraints: 5600000/28173676
processing constraints: 5700000/28173676
processing constraints: 5800000/28173676
processing constraints: 5900000/28173676
processing constraints: 6000000/28173676
processing constraints: 6100000/28173676
processing constraints: 6200000/28173676
processing constraints: 6300000/28173676
processing constraints: 6400000/28173676
processing constraints: 6500000/28173676
processing constraints: 6600000/28173676
processing constraints: 6700000/28173676
processing constraints: 6800000/28173676
processing constraints: 6900000/28173676
processing constraints: 7000000/28173676
processing constraints: 7100000/28173676
processing constraints: 7200000/28173676
processing constraints: 7300000/28173676
processing constraints: 7400000/28173676
processing constraints: 7500000/28173676
processing constraints: 7600000/28173676
processing constraints: 7700000/28173676
processing constraints: 7800000/28173676
processing constraints: 7900000/28173676
processing constraints: 8000000/28173676
processing constraints: 8100000/28173676
processing constraints: 8200000/28173676
processing constraints: 8300000/28173676
processing constraints: 8400000/28173676
processing constraints: 8500000/28173676
processing constraints: 8600000/28173676
processing constraints: 8700000/28173676
processing constraints: 8800000/28173676
processing constraints: 8900000/28173676
processing constraints: 9000000/28173676
processing constraints: 9100000/28173676
processing constraints: 9200000/28173676
processing constraints: 9300000/28173676
processing constraints: 9400000/28173676
processing constraints: 9500000/28173676
processing constraints: 9600000/28173676
processing constraints: 9700000/28173676
processing constraints: 9800000/28173676
processing constraints: 9900000/28173676
processing constraints: 10000000/28173676
processing constraints: 10100000/28173676
processing constraints: 10200000/28173676
processing constraints: 10300000/28173676
processing constraints: 10400000/28173676
processing constraints: 10500000/28173676
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

Circuit

https://github.com/leonardovona/beacon-relay/blob/main/circuits/circuits/step.circom

Steps to reproduce

• Compile the circuit: circom my_step.circom --O1 --r1cs
• Generate the zkey file: node --max-old-space-size=204800 node_modules/.bin/snarkjs zkey new my_step.r1cs powersOfTau28_hez_final_25.ptau my_step.zkey

[Stentonian]

This helped me get around the memory issues:

sysctl -w vm.max_map_count=655300

nodejs/node#27715 (comment)

Note to anyone who got here because they have the same memory issue

valid for Unix systems, not sure about Windows

1. Increase V8 memory

You can increase V8 max memory size with --max-old-space-size=SIZE (in megabytes), which can be done in these ways for Unix systems:

# by exporting an environment variable..
export NODE_OPTIONS="--max-old-space-size=<size>"
# run your node/npx/snarkjs command..

# using a command-scoped environment variable..
NODE_OPTIONS="--max-old-space-size=<size>" # your npx/snarkjs command

# via the node cli option..
node --max-old-space-size=<size> # rest of command

The value does not need to be less than your system memory (although the Nodejs docs do recommend this).

2. Increase kernel memory map per process

The value can be set like so

sysctl -w vm.max_map_count=<size>

The default value is 65530 and a 10x increase seemed to work for me.

[Stentonian]

Here is a bunch of good reading for if you have a large circuit: https://hackmd.io/V-7Aal05Tiy-ozmzTGBYPA?view