-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Invalid model in string formula #5140
Comments
commit: c629f09
|
@veanes @cdstanford : maybe connected with symbolic regexes. (str.to_re b) is symbolic. |
commit: 1fc9a7b
|
These are very interesting non-ground test cases. I verified the buggy behavior for the 5 examples on the most recent commit (1fc9a7b) A slightly simpler version of the second example:
The example behaves correctly if The third example seems to rely on the |
Output of
Abbreviated trace (
Note the line: |
This is because when b = "" appears at top level, then b gets replaced by "" elsewhere and the regex becomes ground.
It simply saturates into a state that is not representative of a solution.
|
Refutation soundness issue (in default mode):
Commit: c0e74f9 |
Another invalid model instance (in default mode):
Commit: c0e74f9 |
Invalid model instance (in default mode):
Commit: c0e74f9 |
Invalid model instance (in default mode):
Commit: c0e74f9 It reproduces for at least as early as z3 4.8.5 and later. |
|
|
Commit: a6ef99d
|
Segfault with release build and assertion failure with debug build (append here since the instance is a string formula):
Commit: a6ef99d |
An invalid model instance (in default mode):
Commit: a6ef99d |
|
Solution soundness issue:
Commit: a6ef99d |
Refutation soundness issue:
Commit: a6ef99d |
|
|
@veanes Did you have a chance to look into these? When solving:
Search reaches a point where it propagates
In response it creates the single axiom:
This axiom is insufficient to enforce that when 'a' has length 1, then the condition of the
must be false.
we see that for this case, the is_nullable check is skipped.
accepts the empty string. It needs to be enforced to handle the case where a has length 1.
is skipped, min_length is UINT_MAX. Indeed, the code for computing "info" has a case where it handles ite expressions.
The definition of "orelse" uses the min_length attribute from i1 but ignores the min_length from i2.
Thus, it would seem the way info is computed and how it gets used needs a revision. |
Commit: 30e904b Another solution unsoundness instance:
|
Commit: 51a4db8 Another (likely related) instance:
|
|
bugs are re-triaged based on fix by @veanes. Several bugs are duplicates either of the fix or of a separate fix during model construction. Bugs that are still valid are marked with a "sad" face. |
Commit: 3a5b88e
|
Commit: 082ec0f Refutation soundness issue (
|
Commit: 2138ef2 Solution unsoundness:
|
Commit: 2138ef2 Invalid model:
|
Commit: 2138ef2 Invalid model:
|
Commit: 2138ef2 (1) Refutation unsoundness with
|
Commit: 2138ef2 Another invalid model instance:
|
Commit: ed9341e Refutation soundness issue:
moved to #5467 |
Invalid model at 45228bf
|
Commit: d5c6abe Solution soundness issue:
|
One more invalid model instance:
|
Refutation soundness issue:
|
Commit: d5c6abe Refutation soundness issue on an incremental instance:
moved to #5467 |
NB: this one is still open
Other reports also not checked with eyes should be examined. |
I investigated this one more closely. If I rewrite it in a more human-readable form it says (using X for a): it currently gives the model X="b" in the latest changes (that is correct -- unless I made a typo somewhere). Observe that ["b"-"u"]&"b" = "b" |
As I was investigating an incorrect unsat above (the case (1) below) I found a weird behavior (1) is unsat (incorrect), but (2) is sat, the only difference between (1) and (2) is that in (1) the uninterpreted symbol is named lower case 'a', in (2) it is named uppercase 'X', as to why that would make any difference -- I don't know, but answers did not change with different random seeds. It seemed pretty consistent that uppercase naming produced the answer sat while lowercase naming produced the answer unsat. (declare-fun a () String) (above is from June 10) (declare-fun X () String) |
typically it is possible to force divergent behavior using different random seeds, but for the above example, the "X" example and "a" example behave differently across different seeds. They induce different hash values so the order of identifiers will be different and then pre-processing and solving can diverge. Even the result of pre-processing is different (seen by adding -tr:asserted_formulas in debug mode) so this is where I would start an investigation. |
thx for the clarification. I'll continue to investigate this one. |
Commit: 32beb91 Refutation unsoundness:
moved to #5467 |
Commit: 5652d2a Segfault (appears to be a recent regression):
|
Solution unsoundness (a recent regression from z3-4.8.12):
|
Invalid model (regression from z3-4.8.10):
|
commit: c629f09
The text was updated successfully, but these errors were encountered: