Skip to content
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

Compiler panic when a slice is modified in multiple if statements. #4202

Closed
Tracked by #3363
pventuzelo opened this issue Jan 30, 2024 · 0 comments · Fixed by #4240
Closed
Tracked by #3363

Compiler panic when a slice is modified in multiple if statements. #4202

pventuzelo opened this issue Jan 30, 2024 · 0 comments · Fixed by #4240
Assignees
Labels
bug Something isn't working
Milestone

Comments

@pventuzelo
Copy link

Aim

We (@FuzzingLabs) found an internal compiler error that occurs when a slice is modified in multiple if statements.

Expected Behavior

The compiler should not panic and handle the valid code properly.

Bug

The panic occurs when a slice is modified in two or more if statements, while these if statements make a comparison with the slice. As you can see in the code comments, every value and type has no impact.
The code attempted to be as minimalist as possible to highlight the source of the error, but it is still challenging to identify the reason without a thorough understanding of the compiler itself.

The error occurs with the latest compiler version of the main branch. The error message is as follows:

The application panicked (crashed).
Message:  ICE: load in merger should have store from outer block
Location: compiler/noirc_evaluator/src/ssa/opt/flatten_cfg/value_merger.rs:259

The panic comes from the line 259 of this file: https://github.com/noir-lang/noir/blob/master/acvm-repo/acir_field/src/generic_ark.rs

To Reproduce

  1. Create a Noir project with the following command: nargo new test_issue
  2. Paste the code below into the file main.nr
  3. Compile the project using the following command: nargo compile
fn main() {

    // The compiler panics with this code.
    // The type, size, and value of the slice don't matter.
    // Indexes and values in the rest of the code don't matter as well.
    let mut slice1: [u32] = [1, 2, 3, 4];
    if slice1[0] == 3 {
        slice1[1] = 4;
    }

    if slice1[1] == 5 {
        slice1[3] = 6;
    }

    // The panic seems to only occur if the slice is modified in two different if statements that include a comparison on the slice.
    // For example, these codes don't panic:

    // Only one if statement
    let mut slice2: [u32] = [1, 2, 3, 4];
    if slice2[0] == 3 {
        slice2[1] = 4;
    } else {
        slice2[3] = 6;
    }

    // Only one slice modification
    let mut slice3: [u32] = [1, 2, 3, 4];
    if slice3[0] == 3 {
        slice3[1] = 4;
    }

    if slice3[1] == 5 {
        // It's a random instruction
        assert(slice3[3] == 6);
    }

    // if statement with no comparison on the slice
    let mut slice1: [u32] = [1, 2, 3, 4];
    if 1 == 3 {
        slice1[1] = 4;
    }

    if slice1[1] == 5 {
        slice1[3] = 6;
    }
}

Installation Method

None

Nargo Version

No response

Additional Context

No response

Would you like to submit a PR for this Issue?

No

Support Needs

No response

@pventuzelo pventuzelo added the bug Something isn't working label Jan 30, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Jan 30, 2024
@kevaundray kevaundray added this to the 0.24 milestone Jan 30, 2024
github-merge-queue bot pushed a commit that referenced this issue Feb 8, 2024
# Description

## Problem\*

Resolves #4202 and
#2446 (comment)
## Summary\*

This PR brings back the `capacity_tracker` that was used by the fill
internal slices pass and for merging nested slices
(#3979). We now track the capacity
of slices as we insert instructions. The capacity tracker has also been
simplified as it no longer needs to handle nested slice.

The current strategy checks for previously saved store instructions and
backtracks the instructions to see what is the capacity of a slice when
it comes time to merge two slice values. This required an additional
`outer_block_stores` map as we `store_values` only track stores within
the current branch that is being inlined, and a `get_slice_length`
method that ultimately did the recursive backtracking to determine the
slice length. With the capacity tracker we already have the slice length
once it comes time to perform a slice merger allowing us to remove
`outer_block_stores` and `get_slice_length`.

Overall, the capacity tracker enables us to have more accurate tracking
of slice capacities and gives us a more general strategy for tracking a
slice capacity per instruction.

## Additional Context

## Documentation\*

Check one:
- [X] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[Exceptional Case]** Documentation to be submitted in a separate
PR.

# PR Checklist\*

- [X] I have tested the changes locally.
- [X] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.

---------

Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
3 participants