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

nargo debug does not step properly any more #5703

Closed
smanilov opened this issue Aug 9, 2024 · 2 comments · Fixed by #5706
Closed

nargo debug does not step properly any more #5703

smanilov opened this issue Aug 9, 2024 · 2 comments · Fixed by #5706
Labels
bug Something isn't working

Comments

@smanilov
Copy link

smanilov commented Aug 9, 2024

Aim

Before #5696 was merged (i.e. syncing at commit 2882eae), nargo debug exhibited the following behavior:

$ cd test_programs/execution_success/inline_never_basic
$ nargo debug
[inline_never_basic] Starting debugger
At opcode 0:0 :: BRILLIG CALL func 0: inputs: [Single(Expression { mul_terms: [], linear_combinations: [(1, Witness(0))], q_c: 0 }), Single(Expression { mul_terms: [], linear_combinations: [(1, Witness(1))], q_c: 0 })], outputs: []
> next
At opcode 0:0.6 :: Const { destination: MemoryAddress(4), bit_size: Integer(U32), value: 0 }
At /home/stan/code/repos/noir-upstream/test_programs/execution_success/inline_never_basic/src/main.nr:1:33
  1 -> fn main(x: Field, y: pub Field) {
  2        basic_check(x, y);
  3    }
  4
  5    #[inline(never)]
  6    fn basic_check(x: Field, y: Field) {
  7        assert(x != y);
  8    ...
> quit
Debugger execution halted.
$ 

After the PR is merged (i.e. syncing at commit e4f7dbe), next seems to step through the whole program and complete the execution:

$ cd test_programs/execution_success/inline_never_basic
$ nargo debug
[inline_never_basic] Starting debugger
At opcode 0:0 :: BRILLIG CALL func 0: inputs: [Single(Expression { mul_terms: [], linear_combinations: [(1, Witness(0))], q_c: 0 }), Single(Expression { mul_terms: [], linear_combinations: [(1, Witness(1))], q_c: 0 })], outputs: []
> next
Finished execution
> quit
Debugger execution halted.
$ 

Alternatively, one could step through the program using the into command in the debugger. However, the call stack is still not displayed when functions are entered, while this used to be the case before the problematic PR.

I suspect that the source-mapping information is somehow lost after the change.

Could you please roll-back the change?

Expected Behavior

  1. nargo debug can be used to step through the program line by line via the next command.
  2. The into command steps through instructions and displays the call stack when functions are entered.

Bug

  1. The next command just terminates the execution; possibly, because the debugger does not recognize that the program contains any source lines.
  2. The into command steps through instructions but does not display the call stack when functions are entered.

To Reproduce

  1. navigate to test_programs/execution_success/inline_never_basic
  2. run nargo debug
  3. issue a next command

The debugger completes the execution, rather than stepping to the first source line (this used to be the behavior before).

Workaround

None

Workaround Description

No response

Additional Context

No response

Project Impact

Blocker

Blocker Context

We are leveraging the debugger in a tracer that we've built in the blocksense-network/noir fork. Now that it's not working as before, our tracer is broken.

Nargo Version

nargo version = 0.33.0 noirc version = 0.33.0+e4f7dbe63b55807b3ff0b4d6f47a8b7f847299fb (git version hash: e4f7dbe, 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

@smanilov smanilov added the bug Something isn't working label Aug 9, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Aug 9, 2024
@smanilov
Copy link
Author

smanilov commented Aug 9, 2024

FYI @vezenovm @jfecher

smanilov added a commit to blocksense-network/noir that referenced this issue Aug 9, 2024
No conflicts, but upstream have broken `nargo debug` and thus `nargo
trace`.

This commit changes the trace tests so that they now assert that the
traces do not match. When the bug is fixed, these tests should fail
again, which would be a way for us to detect the fix, if everything else
fails.

Bug here: noir-lang#5703
@smanilov
Copy link
Author

I see the PR that's opened to fix this. Thanks for taking a look.

github-merge-queue bot pushed a commit that referenced this issue Aug 12, 2024
…tadata format (#5706)

# Description

## Problem\*

Resolves #5703 

## Summary\*

After #5696 debug metadata from
Brillig functions was de-duplicated to avoid a blow-up in artifact size.
The debugger uses this debug metadata format to accurately display
information in the REPL and DAP interface. This PR contains the updates
needed for the debugger to handle the new debug metadata format.

The debugger on `inline_never_basic` (the example used in the linked
issue) gives the following again:
<img width="696" alt="Screenshot 2024-08-09 at 2 28 56 PM"
src="https://github.com/user-attachments/assets/c9232c8d-34f7-45fc-94f1-be51b75dd07c">

The output matches what was on master before PR #5696.

## Additional Context


## Documentation\*

Check one:
- [X] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** 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.
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Aug 12, 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
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant