-
Notifications
You must be signed in to change notification settings - Fork 261
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
If Z3 can't be run, Dafny sometimes hangs instead of reporting an error #2370
Comments
I just noticed #1914. The two issues may have the same root cause, in which case it probably makes sense to broaden one of them and mark the other as a duplicate. |
I suspect they will need separate fixes, since the CLI should print out an error but the language server will need to provide a different notification. Perfectly fine for one PR to fix both though. :) |
I've had Dafny verification hang when it passed incorrect parameters to Z3, which happened because it passed parameters for Z3 4.8.5, while it was using Z3 4.8.8 |
How long ago did you have that issue @keyboardDrummer ? |
Today |
CLI or language server? If CLI, what was the command line you ran? |
The language server, it passed |
The language server is supposed to have code to send the right options to Z3, the method |
Oh that's concerning. |
* Be more explicit about the path of the executable to invoke. * Identify the version and set different Z3 options accordingly. Fixes dafny-lang#2370 Enables a fix for dafny-lang#1477 Interacts with dafny-lang#1914 (which may already be fixed)
* Be more explicit about the path of the executable to invoke. * Identify the version and set different Z3 options accordingly. Fixes #2370 Enables a fix for #1477 Interacts with #1914 (which may already be fixed) By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.
* Be more explicit about the path of the executable to invoke. * Identify the version and set different Z3 options accordingly. Fixes dafny-lang#2370 Enables a fix for dafny-lang#1477 Interacts with dafny-lang#1914 (which may already be fixed) By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.
* Be more explicit about the path of the executable to invoke. * Identify the version and set different Z3 options accordingly. Fixes dafny-lang#2370 Enables a fix for dafny-lang#1477 Interacts with dafny-lang#1914 (which may already be fixed) By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.
This still seems to occur sometimes. We should more thoroughly check the case where a z3 binary exists but can't be executed for some reason (being an incompatible version, having missing shared library dependencies, etc.). |
Do we currently run any kind of "smoke test" against the specified solver binary, to check that the binary is available and provides a known result, before using it? I see that we run |
Not at the moment. I think it might be good to do that. And I think perhaps we should fail if we don't get anything back from |
Stepping back: How did a failure to run the solver cause Dafny to hang in the first place? Can we change that hang to an error rather than relying solely on up-front smoke tests? No matter how many smoke tests we add, we may overlook some unusual scenario that may affect some user. |
I've looked into this a little, and it's unfortunately a bit tricky to do. From what I can tell, the .NET |
I updated the title accordingly. The case I'm interested in right now is having broken shared library dependencies since I've run into it in my work at Amazon.
I find it hard to believe that such an important, widely used class would have that kind of fundamental bug; it seems much more likely to me that the problem is elsewhere. So out of curiosity, I debugged Dafny in my current case where Z3 has broken shared library dependencies, and I think I found the root cause of the hang in that case. This line propagates an IOException without releasing
The IOException is correctly handled here, but Dafny goes on to verify the next method without Note: When I tried the new command line format ( If I make the following change to the Boogie code, then Dafny no longer hangs: diff --git a/Source/VCGeneration/CheckerPool.cs b/Source/VCGeneration/CheckerPool.cs
index e4c45182..d51fef17 100644
--- a/Source/VCGeneration/CheckerPool.cs
+++ b/Source/VCGeneration/CheckerPool.cs
@@ -32,8 +32,13 @@ public async Task<Checker> FindCheckerFor(ConditionGeneration vcgen, Split? spli
checker ??= CreateNewChecker();
}
- PrepareChecker(vcgen.program, split, checker);
- return checker;
+ try {
+ PrepareChecker(vcgen.program, split, checker);
+ return checker;
+ } catch (System.IO.IOException) {
+ checkersSemaphore.Release();
+ throw;
+ }
}
private int createdCheckers; I'm sharing this as a proof of concept. There may be any number of reasons it may not be the best fix. For example, maybe we should call Again, this is for the case where Z3 has broken shared library dependencies. I don't know whether there are other ways in which Z3 could fail that would cause the Dafny/Boogie code to fail in a different place. |
Thanks for digging so deeply into debugging the issue! That should be a straightforward fix to apply. |
And @keyboardDrummer ended up fixing it: boogie-org/boogie#719 I'll leave this open until we've updated Dafny to depend on that Boogie version and tested it from the Dafny side, though. |
The Boogie fix was incorporated in 6675361. The problem doesn't appear to exist anymore, in the tests I've tried. |
In some cases in which Dafny can't find Z3, Dafny hangs instead of reporting the expected error "Cannot find any prover executable". This can make it confusing for the user to troubleshoot the problem. Failure to find Z3 isn't likely to happen when using a binary release of Dafny that has Z3 bundled at the right path, but it can happen when building Dafny from source or using a custom build system.
Steps to reproduce (tested on my Linux machine):
dafny/z3
directory.hang-test.dfy
../dafny/dafny /compile:0 hang-test.dfy
Example code:
Expected behavior: Dafny exits with an error message, "Cannot find any prover executable".
Actual behavior: Dafny hangs.
Some further testing I did suggests that the hang happens when the number of methods to be verified is greater than the value of the
/vcsCores
option, which defaults to 1. With the example code above (which has 3 methods), I observe:./dafny/dafny /compile:0 /vcsCores:3 hang-test.dfy
->Cannot find any prover executable
(within a few seconds)./dafny/dafny /compile:0 /vcsCores:2 hang-test.dfy
-> hangSo this may be some kind of deadlock in a thread pool.
The text was updated successfully, but these errors were encountered: