You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If exceptions arise during interaction with a solver, VCGen.VerifyImplementation can sometimes silently and erroneously return Correct. In particular, I've seen this arise twice:
When incorrectly implementing a new feature in NoopSolver that led to an exception in SMTLibProcessTheoremProver.GetRCount.
When attempting to use Dafny with Yices and configuring it incorrectly.
You can replicate this by putting the following in an executable file named badz3:
#!/bin/bash
echo "dfksal"
And then running Boogie with the prover set to that script, something like this:
I was hoping that changing Correct to Inconclusive here would resolve the issue, and that later code would set the outcome to Correct when encountering concrete evidence of correctness (e.g., "unsat" from a prover). However, it seems as though later code depends on this initial value, so I'm still investigating the appropriate fix.
The text was updated successfully, but these errors were encountered:
If exceptions arise during interaction with a solver,
VCGen.VerifyImplementation
can sometimes silently and erroneously returnCorrect
. In particular, I've seen this arise twice:NoopSolver
that led to an exception inSMTLibProcessTheoremProver.GetRCount
.You can replicate this by putting the following in an executable file named
badz3
:And then running Boogie with the prover set to that script, something like this:
This leads to the following output:
When running with a working Z3, it reports 8 verified, 2 errors.
I believe that the issue arises at least in part from the following line:
boogie/Source/VCGeneration/VCGen.cs
Line 839 in da30caa
I was hoping that changing
Correct
toInconclusive
here would resolve the issue, and that later code would set the outcome toCorrect
when encountering concrete evidence of correctness (e.g., "unsat" from a prover). However, it seems as though later code depends on this initial value, so I'm still investigating the appropriate fix.The text was updated successfully, but these errors were encountered: