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

Halmos fails with Z3Exception: b'parser error' #402

Open
Tracked by #346
aviggiano opened this issue Nov 7, 2024 · 4 comments · May be fixed by #414
Open
Tracked by #346

Halmos fails with Z3Exception: b'parser error' #402

aviggiano opened this issue Nov 7, 2024 · 4 comments · May be fixed by #414
Labels
bug Something isn't working

Comments

@aviggiano
Copy link
Contributor

Describe the bug

When running Halmos on a relatively simple project that uses assembly, it fails wit the following error: Z3Exception: b'parser error'

To Reproduce

git clone https://github.com/aviggiano/halmos-modexp
cd halmos-modexp
halmos

Environment:

  • OS: macOS
  • Python version: Python 3.12.6
  • Halmos and other dependency versions: halmos 0.2.1.dev16+g1502e46

Additional context

N/A

@aviggiano aviggiano added the bug Something isn't working label Nov 7, 2024
@karmacoma-eth
Copy link
Collaborator

thanks for the easy repro, it's an internal error. We pass an internal ByteVec type to the Z3 API, which it doesn't know how to handle. We need to unwrap it into a type that Z3 supports and add a unit test for modexp

@daejunpark daejunpark mentioned this issue Nov 13, 2024
17 tasks
karmacoma-eth added a commit that referenced this issue Nov 14, 2024
@karmacoma-eth karmacoma-eth linked a pull request Nov 14, 2024 that will close this issue
@karmacoma-eth
Copy link
Collaborator

so I started working on the internal error, but if I understand your test correctly we won't be able to support it in full. The reason is that there is no modexp operator in SMT, so we can't directly ask the solver to show that it is equivalent to an actual computation.

IOW, we will support a black-box version of modexp (an "uninterpreted function" in SMT jargon), so the solver will know how to compare modexp(b1, e1, m1) to modexp(b2, e2, m2), but not to actual values

@aviggiano
Copy link
Contributor Author

Makes sense, thanks

Is that the same as you do for the other precompiles?

@karmacoma-eth
Copy link
Collaborator

it's on a case by case basis, but it is the same for e.g. keccak, vm.addr, or ecrecover. Anything where we don't really have a choice but keep the values opaque to the solver

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
None yet
Development

Successfully merging a pull request may close this issue.

2 participants