Closed facferreira closed 6 years ago
I have exactly the same problem (briefly reported in Issue #1097). I subscribe myself to this Issue since I am also interested in the answer.
What kind of solver are you using, i.e. how did you get your solver
object?
Simply by doing context.mkSolver(); (The context was created with an empty map)
to properly repro this one would need a log (Z3_open_log before any context is created) or a java version.
Hi, I am facing the same issue (working on the same project).
I am compiling a test to reveal 3 different errors related to Java bindings. This is the first one, in which two different SMT2 models (generated by the Java bindings) both have inconsistent behaviours:
Test consists on loading the smt2 model, and checking for sat. No defaults are set.
Java Bindings: unknown Python z3: unsat z3 command-line: unsat
I am providing everything to reproduce the problem in the following repo, including how to generate the models, the output in both MacOS and Linux of the different bindings, and the outputs/$os_execution/$file_model.log resulted from using z3's openlog.
https://github.com/alcides/z3test (Problem 2 in the Readme.md)
Any update on this issue? This is preventing us from working on this project, not being able to trust the z3 Java bindings.
Same here. Our project is in standby, waiting for this issue with Z3 to be solved...
Is it possible to get a "z3.log" file from the Java interaction and the python interaction as well? The API for creating a log file is called Z3_open_log and there are Java versions of this (from Python just invoke z3.Z3_open_log directly). I assume you are using Z3 from a single thread as the logging features are not supported for multiple threads.
This would make it possible to debug the "unknown" vs. "unsat" behavior. The python and Java behavior should be similar, the only exception is the order in which expressions are built. You can emulate checking different expression orders by setting the parameter smt.random_seed to different values and check if the solver returns alternations of "unknown" vs. "unsat".
Here you have the two logs of one such example:
https://github.com/alcides/z3test/blob/master/linux.smt2_python.log
https://github.com/alcides/z3test/blob/master/linux.smt2_java.log
And they provide different answers (unsat vs. unknown)? Seem they were generated for 4.6.0 and not current 4.6.1.
Yes, they do. On 3 different (but somehow similar) smt2 models.
I used commit 1323b8f63f21f40b7a264140ff84afa3dad989c8, which i believe its close to 4.6.1. I'll run with the newest version, but I believe the problem remains.
The same behaviour occurs with small.smt2.
macos.smt2 and linux.smt2 now fail to parse on command-line z3 and python bindings with the latest z3 version. Java still gives unknown on both examples.
Despite the version strings, it was executed with all bindings compiled from the commit fbbc57168d8e66979bf61ff4cfa355f9351d98c8.
OS: Darwin x86_64
--------- Java version ---------
Z3 Full Version String: Z3 4.6.0.0
-------- Python version -------
Z3 4.6.1.7919 master z3-4.6.0-143-gfbbc5716
----- Command-line version -----
Z3 version 4.6.1 - 64 bit
--------------------------
Model: linux.smt2
cmline: (error "line 63 column 46: unknown function/constant is-G")
unsat
(error "line 63 column 46: unknown function/constant is-G")
Traceback (most recent call last):
File "t.py", line 10, in <module>
s.from_file(fname)
File "/usr/local/lib/python2.7/site-packages/z3/z3.py", line 6333, in from_file
_handle_parse_error(e, self.ctx)
File "/usr/local/lib/python2.7/site-packages/z3/z3.py", line 8104, in _handle_parse_error
raise ex
z3.z3types.Z3Exception: parser error
WARNING: an assumption must be a propositional variable or the negation of one
java: UNKNOWN
java reason: unknown
--------------------------
Model: macos.smt2
cmline: (error "line 62 column 46: unknown function/constant is-G")
sat
(error "line 62 column 46: unknown function/constant is-G")
Traceback (most recent call last):
File "t.py", line 10, in <module>
s.from_file(fname)
File "/usr/local/lib/python2.7/site-packages/z3/z3.py", line 6333, in from_file
_handle_parse_error(e, self.ctx)
File "/usr/local/lib/python2.7/site-packages/z3/z3.py", line 8104, in _handle_parse_error
raise ex
z3.z3types.Z3Exception: parser error
WARNING: an assumption must be a propositional variable or the negation of one
java: UNKNOWN
java reason: unknown
--------------------------
Model: small.smt2
cmline: unsat
python: unsat
WARNING: an assumption must be a propositional variable or the negation of one
java: UNKNOWN
java reason: unknown
The version string in the log files should be along the lines of: V "4.6.1.0 Feb 27 2018"
I am unable to run your logs using the current master. Sometimes Java installations have been seen picking up stale versions of libz3.dll
I am now running this version: https://github.com/Z3Prover/bin/commit/b6ffdb1fbceaaf01da6d2b6ca0b1071caf8aa87f
It seems that SIP on MacOS prevents -Djava.library.path from ever being used (https://github.com/Z3Prover/z3/issues/294). Unfortunately Apple does not fix this issues, but there should be a clear warning in the z3 documentation that dylibs should be in the current path on MacOS.
However, using the same version, Java still produces unknown while Python produces unsat.
The new logs are available here:
https://github.com/alcides/z3test/blob/master/small.smt2_java.log https://github.com/alcides/z3test/blob/master/small.smt2_python.log
The Java trace triggered some debug asserts that I have taken care of now, but they should be benign. For these two traces the calls into the APIs are different.
For Java: 3:Z3_mk_config 5:Z3_set_param_value 7:Z3_mk_context_rc 4:Z3_del_config 328:Z3_set_ast_print_mode 338:Z3_get_error_code 335:Z3_parse_smtlib2_string 338:Z3_get_error_code 255:Z3_get_ast_kind 338:Z3_get_error_code 252:Z3_get_sort 338:Z3_get_error_code 207:Z3_get_sort_kind 338:Z3_get_error_code 258:Z3_is_algebraic_number 338:Z3_get_error_code 257:Z3_is_numeral_ast 338:Z3_get_error_code 256:Z3_is_app 338:Z3_get_error_code 9:Z3_inc_ref 338:Z3_get_error_code 407:Z3_mk_solver 338:Z3_get_error_code 415:Z3_solver_inc_ref 338:Z3_get_error_code 427:Z3_solver_check_assumptions 338:Z3_get_error_code 433:Z3_solver_get_reason_unknown 338:Z3_get_error_code
For Python: 3:Z3_mk_config 7:Z3_mk_context_rc 338:Z3_get_error_code 328:Z3_set_ast_print_mode 338:Z3_get_error_code 4:Z3_del_config 407:Z3_mk_solver 338:Z3_get_error_code 415:Z3_solver_inc_ref 338:Z3_get_error_code 424:Z3_solver_from_file 338:Z3_get_error_code 427:Z3_solver_check_assumptions 338:Z3_get_error_code
(I get this by rerunning the logs and then tracing -tr:z3_replayer_cmd)
The Java version calls the parse_smtlib2_string function. The Python version calls solver_from_string, which loads assertions into the solver object. The Java trace never adds the assertions to the solver, so the solver call is trivial.
I fixed this issue, calling Solver.fromFile()
In retrospective, I believe this was the result from unclear Java bindings documentation. I will try to improve it, if I find the time.
You can close this.
So if I write:
/**
* Parse the given string using the SMT-LIB2 parser.
*
* @return A conjunction of assertions.
* If the string contains push/pop commands, the
* set of assertions returned are the ones in the
* last scope level.
**/
Hi, using the Java API I'm adding assertions, to which I check if they are satisfiable, expecting the Java API to return unsat. However, the Java API is returning unknown (due to incomplete quantifiers) but when I save in a file the result of solver.toString() (that produced the unknown result) and adding a (check-sat) to the file, in the commandline-tool it returns unsat as I expected.
Here is the result of solver.toString():
Curiously, if I try using the Java API parse from that file (after removing the duplicated lines generated by solver.toString() and removing the (check-sat)):
The Java API returns unsat correctly. So, my question is, why is that after creating the assertions using the Java API and checking if satisfiable it returns unknown but using the commandline-tool/parsing it returns unsat correctly?
Thanks.