Open mikirov opened 10 months ago
Hi @mikirov, the code you've pasted doesn't contain a main
function so it shouldn't compile. Can you give a full example?
Hi @mikirov, the code you've pasted doesn't contain a
main
function so it shouldn't compile. Can you give a full example?
I am sorry, I updated the proper code :). Complete repo with the code can be found here
Hi @mikirov, thanks for reporting the issue.
Got a 404 when accessing the repo you linked to. Perhaps it's a private repo still?
Also what is the boundary you are facing in terms of the number of private inputs that makes a successful vs failing compilation?
Investigating further it seems like I could not find a link from the stack overflow to the private inputs. I tried nargo compile --show-ssa
, which produced 454265 lines after which the process aborted. I was suspecting i did not have enough RAM to run the process on my local machine, however running it on 177GB RAM GCP VM had the same stack overflow issue. Debugging further, /usr/bin/time -h -p -l nargo compile
says the peak RAM usage of the process was mere 1.2GB:
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
time: command terminated abnormally
real 2.18
user 1.85
sys 0.25
1798160384 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
123062 page reclaims
0 page faults
0 swaps
0 block input operations
0 block output operations
0 messages sent
0 messages received
1 signals received
1 voluntary context switches
439 involuntary context switches
20707369774 instructions retired
6454949306 cycles elapsed
1205850816 peak memory footprint
[1] 58309 abort /usr/bin/time -h -p -l nargo compile
Is it possible that there is a limit in the number of generated ACIR operations in a stack frame imposed by barretemberg?
What are the constraint counts you get from running nargo info
?
Commenting out parts of the main method I was able to run nargo compile
successfully. Seems like the issue is not in the number of private inputs but rather the number of constraints generated in the main method. Removing one of 3 merkle inclusion proofs makes the program compile successfully.
I managed to find a workaround using recursive proofs. Maybe there should be a better error message when the circuit size is too large?
Maybe there should be a better error message when the circuit size is too large?
At what circuit sizes were you hitting the "ceiling" and received the error?
Aim
The program should compile or give a more descriptive error message why it could not compile
Expected Behavior
The program should compile or give a more descriptive error message why it could not compile
Bug
The code that fails is the following:
To Reproduce
nargo compile
nargo execute
Installation Method
Binary
Nargo Version
nargo version = 0.19.2 noirc version = 0.19.2+47f0130c0d154f1b70eb23f376783beb3f23ad72 (git version hash: 47f0130c0d154f1b70eb23f376783beb3f23ad72, is dirty: false)
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response