-
Notifications
You must be signed in to change notification settings - Fork 310
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
fix: Fix integration test failures for sync-noir #11294 #11448
Conversation
getting test failures on here btw. |
After fixing the "subtract with overflow" issue, I'm now investigating the contract test failures like so: Rebuild the contracts: cd aztec-packages
./noir/bootstrap.sh
./noir-projects/bootstrap.sh
./yarn-project/bootstrap.sh Start an execution server to serve as an oracle: export LOG_LEVEL=debug
cd ./yarn-project/txe
yarn start Then run one of the failing tests from ci-noir-bb: export NARGO=$(pwd)/noir/noir-repo/target/release/nargo
cd ./noir-projects/noir-protocol-circuits
$NARGO test --silence-warnings --oracle-resolver http://localhost:8080 --package private_kernel_lib validate_sorted_siloed_nullifiers_succeeds |
inc_rc
on input arrays during preprocessing
Running the above reveals an ICE: % $NARGO test --silence-warnings --oracle-resolver http://localhost:8080 --package private_kernel_lib validate_sorted_siloed_nullifiers_succeeds 8s ~/aztec-packages/noir-projects/noir-protocol-circuits af/fix-11294+ akosh-box
[private_kernel_lib] Running 1 test function
The application panicked (crashed).
Message: internal error: entered unreachable code: All Value::Instructions should already be known during inlining after creating the original inlined instruction. Unknown value v39154 = Instruction { instruction: Id(54188), position: 0, typ: Numeric(NativeField) }
Location: compiler/noirc_evaluator/src/ssa/opt/inlining.rs:696
This is a bug. We may have already fixed this in newer versions of Nargo so try searching for similar issues at https://github.com/noir-lang/noir/issues/.
If there isn't an open issue for this bug, consider opening one at https://github.com/noir-lang/noir/issues/new?labels=bug&template=bug_report.yml
[private_kernel_lib] Testing tests::reset_output_validator_builder::validate_sorted_siloed_nullifiers::validate_sorted_siloed_nullifiers_succeeds... FAIL
An unexpected error happened
[private_kernel_lib] Failures:
tests::reset_output_validator_builder::validate_sorted_siloed_nullifiers::validate_sorted_siloed_nullifiers_succeeds
[private_kernel_lib] 1 test failed |
Random observations: If I run the following to show the SSA before the 2nd inlining pass, it crashes during the normalisation of IDs:
But if I show all SSA passed, then the test passes as well, ie. normalising the IDs after each pass does something to keep the issue from surfacing:
It is true that if I print the non-normalised SSA, then there is this line in it:
and that is the only occurrence of Using the above command to probe passes, the first one which fails is Loop Invariant Code Motion; at static_assert and assert_constant we're still okay (or at least not crashing). I can confirm that with |
Looking the not normalized SSA before the
After the
Again this is not normalised, but display of values calls resolve, so if there was a forwarding path from v39154 to v51608 it would match. |
The reason for this error is that this loop processes blocks ordered by ID rather than a topological order of the call graph, and in this case that means processing This should be fixed in noir-lang/noir#7140 |
Fixes the regression with the
private-kernel-inner-simulated
circuit in #11294 by ensuring thatinc_rc
on arrayinputsoutputs of functions are kept in tactduring the preprocessing step.See #11294 (comment) for more details.
What seems to happen is that normally the DIE pass runs on fully inlined functions, and considers
inc_rc
on arrays that the function did not mutate as unnecessary. However in this case we consider functions in isolation; in our case thenew_from_previous_kernel
took an array as input, determined its length, then passed it toBoundedVec::from_parts_unchecked
which used the array asstorage
. Later another function calledpop
on the vector, which does usearray_set
, but becausenew_from_previous_kernel
didn't know about it, theinc_rc
got removed, and laterpop
thought it was safe to modify the array, rather than make a copy.