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

Possible regression between 4.12.1 and 4.13.0 #7255

Closed
blishko opened this issue Jun 17, 2024 · 6 comments
Closed

Possible regression between 4.12.1 and 4.13.0 #7255

blishko opened this issue Jun 17, 2024 · 6 comments
Labels

Comments

@blishko
Copy link

blishko commented Jun 17, 2024

Hi @NikolajBjorner , @agurfinkel!

In SolCMC, we have observed some regressions on our test suite when attempting to upgrade Z3 from 4.12.1 to 4.13.0.
I have prepared a simplified example here.
When running z3 with the option fp.xform.inline_eager=false, version 4.13.0 hangs, while version 4.12.1 solves it immediately.
Note that both fp.xform.inline_eager=false and (set-option :produce-proofs true) in the file are required for 4.13.0 to hang.

Let me know, if I should try to minimize the example even further. I could spend more time on this, if the cause is not anything obvious.

@agurfinkel
Copy link
Collaborator

Adding @hgvk94 . Hari had some local changes that have not yet been migrated to master. We need to check whether they address the issue.

@blishko
Copy link
Author

blishko commented Jul 11, 2024

Would it help if I try to minimize the example further?

@hgvk94
Copy link
Contributor

hgvk94 commented Jul 11, 2024

Thanks. The example is simple enough. Looks like Spacer is getting stuck in the proof generation phase. Debugging this ...

@hgvk94
Copy link
Contributor

hgvk94 commented Jul 12, 2024

[updates] Spacer is getting stuck in an SMT query made to the solver during proof generation. The query is here. This is commit that introduced this problem: d0d434e
Debugging it now ...

@hgvk94
Copy link
Contributor

hgvk94 commented Aug 3, 2024

The problem is when creating a model for an array expression. The final_check method attempts to merge all enodes that are not equal here. However, with the new is_unique_value implementation in d0d434e, the mk_eq_atom method returns false. Now the array solver thinks it merged two enodes together by adding a new equality atom, but in reality, it's just adding false. This causes an infinite loop in the final_check method

hgvk94 added a commit to hgvk94/z3 that referenced this issue Aug 3, 2024
NikolajBjorner added a commit that referenced this issue Aug 3, 2024
Signed-off-by: Nikolaj Bjorner <nbjorner@microsoft.com>
NikolajBjorner added a commit that referenced this issue Aug 3, 2024
Signed-off-by: Nikolaj Bjorner <nbjorner@microsoft.com>
@blishko
Copy link
Author

blishko commented Sep 10, 2024

I have tried rerunning the benchmarks with master and they now work fine.
I am closing this issue and I am looking forward to a new release!

@blishko blishko closed this as completed Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants