Stack trace order in nargo debug is broken

[smanilov]

Aim

Use nargo debug to inspect the stack trace of a simple program.

Expected Behavior

Before #7163, nargo debug used to work in the following way.

Consider the program:

fn bar(y: Field) {
    assert(y != 0);
}

fn foo(x: Field) {
    bar(x)
}

fn main(x: Field, y: pub Field) {
    foo(x);
    foo(y);
    assert(x != y);
}

When running nargo debug on it, and stepping until the assert(y != 0); line, the printed trace is the following:

> next
At opcode 0:0.25 :: Const { destination: Relative(8), bit_size: Integer(U32), value: 0 }
At /home/aristotelis/code/repos/clone_fast/tmp_sync/test_programs/plonky2_trace/2_function_calls/src/main.nr:10:5
  5    ...
  6        bar(x)
  7    }
  8    
  9    fn main(x: Field, y: pub Field) {
 10 ->     foo(x);
 11        foo(y);
 12        assert(x != y);
 13    }
At /home/aristotelis/code/repos/clone_fast/tmp_sync/test_programs/plonky2_trace/2_function_calls/src/main.nr:6:5
  1    fn bar(y: Field) {
  2        assert(y != 0);
  3    }
  4    
  5    fn foo(x: Field) {
  6 ->     bar(x)
  7    }
  8    
  9    fn main(x: Field, y: pub Field) {
 10        foo(x);
 11    ...
At /home/aristotelis/code/repos/clone_fast/tmp_sync/test_programs/plonky2_trace/2_function_calls/src/main.nr:1:18
  1 -> fn bar(y: Field) {
  2        assert(y != 0);
  3    }
  4    
  5    fn foo(x: Field) {
  6        bar(x)
  7    }
  8    ...
> q

Note that the order of the stack frames here is correct. First is main, then foo, then bar. This is chronological. This happens after about 6 steps into the program (six times calling next in the debugger CLI).

Bug

#7163 seems to break nargo debug in the following way.

With the same program, nargo debug prints the following stack trace after a few next commands:

> next
At opcode 0:0.25 :: Const { destination: Relative(8), bit_size: Integer(U32), value: 0 }
At /home/aristotelis/code/repos/clone_fast/tmp_sync/test_programs/plonky2_trace/2_function_calls/src/main.nr:10:5
  5    ...
  6        bar(x)
  7    }
  8    
  9    fn main(x: Field, y: pub Field) {
 10 ->     foo(x);
 11        foo(y);
 12        assert(x != y);
 13    }
At /home/aristotelis/code/repos/clone_fast/tmp_sync/test_programs/plonky2_trace/2_function_calls/src/main.nr:1:18
  1 -> fn bar(y: Field) {
  2        assert(y != 0);
  3    }
  4    
  5    fn foo(x: Field) {
  6        bar(x)
  7    }
  8    ...
At /home/aristotelis/code/repos/clone_fast/tmp_sync/test_programs/plonky2_trace/2_function_calls/src/main.nr:6:5
  1    fn bar(y: Field) {
  2        assert(y != 0);
  3    }
  4    
  5    fn foo(x: Field) {
  6 ->     bar(x)
  7    }
  8    
  9    fn main(x: Field, y: pub Field) {
 10        foo(x);
 11    ...
> 
CTRL-C

Note that the order in which the stack frames are printed is not the order in which they are created: main is first, bar is next, foo is last. It should be main -> foo -> bar, because that's the chronological order in which they appear.

To Reproduce

1. Create a project using nargo new;
2. Replace the source in src/main.nr with the sample program;
3. For Prover.toml, use x = 4 and y = 5;
4. Run nargo debug and step until the assert line.

Workaround

Yes

Workaround Description

Reverting the changes in preprocess_fns.rs from #7163 fixes the issue.

But, we suspect the issue is in nargo debug itself.

Additional Context

No response

Project Impact

Blocker

Blocker Context

This is blocking other work we're doing in our fork of Noir in https://github.com/blocksense-network/noir , so we have a temporary patch, but we'd love it if this is fixed upstream.

Nargo Version

nargo version = 1.0.0-beta.1 noirc version = 1.0.0-beta.1+c44b62615f1c8ee657eedd82f2b80e2ec76c9078 (git version hash: c44b626, is dirty: false)

NoirJS Version

No response

Proving Backend Tooling & Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[TomAFrench]

I think this is a duplicate issue of #7093 with them both sharing the same root cause.

[smanilov]

Thanks for the reply! Might be the same root cause, although we experienced the issue only yesterday. nargo debug was working fine on Friday. #7093 is from two weeks ago.

[asterite]

I'm trying it right now in master and seeing correct behavior. I can also confirm that it was broken in c44b626

Using git bisect it seems this was fixed by #7212

[michaeljklein]

@asterite yes, it appears so: I'm regression testing this in #7233