That is very interesting.. I use debian buster => z3-4.4.1
I could try to upgrade and see if I can reproduce your problems.. however I think you are debugging a somewhat different issue. I guess our code might not work well with latest z3 and we should fix that..
but then there is something missing in the z3 expressions also I believe that is different. I can look at that detail.
I wonder if you can run the expressions manually on the command line. I wonder if you can reproduce some exception on the command line.. then maybe you can try out some alternative fixed expressions more easily? Maybe something in the syntax needs to be changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is my first time using z3. As of right now I can defiantly run any examples you all give me... I need to go spend a night or two reading about z3 syntax just to make sure I understand a few things. Just looking at it looks like it's in polish notation. But I just need to work through some examples.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now the false positive is gone for me. Note I use the old Z3.. this might not compile at all for you.. it would be interesting to know what happens for you..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a correct z3 expression. It can be solved through z3 CLI utility. But for some reasons it gives me z3: ast is not an expression in C++ code. This is interesting, probably another bug in z3 API?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm still unable to get to my linux computer to test. Below is the rough version of a bash script I used on centos 7 to build cppcheck and z3. I know I have the devtoolset-9 installed.
Does cppcheck get the exception with z3-4.4.1? When I get a chance it's not to hard for me to build other tagged versions of z3. I can always gdb into z3 and try and back solve from the exception.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure about 4.4.1, but I get this exception with upstream z3 built from sources (commit *
28a6da4532c952a7077d233421aa498f5ca2ff59). The backtrace leads to check_error* call inside get_sort function for the result expression. I haven't looked deeper yet, but it seems, that something goes wrong in C part of z3 sources.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One thing I was thinking might be useful is units. ValueUnit("miles per hour") It would allow for the possiblity of add maybe a limits file. So you can uses the speed of light or speed of sound for miles per hour. For temperatures you could use the melting point of tungsten. I could see this being useful for bug hunting in a use case where someone says my program should have no speeds faster than the speed of sound. It would make better constraints than max size of a double.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is very interesting.. I use debian buster => z3-4.4.1
I could try to upgrade and see if I can reproduce your problems.. however I think you are debugging a somewhat different issue. I guess our code might not work well with latest z3 and we should fix that..
but then there is something missing in the z3 expressions also I believe that is different. I can look at that detail.
I wonder if you can run the expressions manually on the command line. I wonder if you can reproduce some exception on the command line.. then maybe you can try out some alternative fixed expressions more easily? Maybe something in the syntax needs to be changed.
I am able to run expressions on the command line. I ran the example bellow
It dose return unsat
This is my first time using z3. As of right now I can defiantly run any examples you all give me... I need to go spend a night or two reading about z3 syntax just to make sure I understand a few things. Just looking at it looks like it's in polish notation. But I just need to work through some examples.
I can locally fix so it works for me. In the function
z3::expr getExpr(ExprEngine::ValuePtr v)
I do this:old code:
new code:
Now the false positive is gone for me. Note I use the old Z3.. this might not compile at all for you.. it would be interesting to know what happens for you..
I made the update.
For me to see if the false positive goes away I will need to recompile the released version of z3. But looking at gdb that is coming from
~~~
z3::expr getExpr(const ExprEngine::BinOpResult *b) {
....
if (b->binop == ">")
return op1 > op2; <<< HERE
~~~
So it looks like I'm not even getting to ExprEngine::FloatRange::isLessThan any more.
I pushed my fix.. so I wonder if you could get latest cppcheck and try it out.
That is very confusing.
I have installed ubuntu 20.10 with z3 4.8.8 on a VM.. I will experiment a bit with that..
Sure it will take me a little time before I'm back in front of my computer, but are there any other test you would like me to run while I'm set up?
If you are more interested in the ValueRange then look in
checkAssignment
:https://github.com/danmar/cppcheck/blob/2a05bc565d/lib/bughuntingchecks.cpp#L632
Feel free to fix that code to handle floats better.
This is very tricky. I do not understand why we get the "z3: ast is not an expression" output! But I can also reproduce it when running ubuntu 20.10.
The easiest way to debug this is to print the generated expression using std::cout << solver; here.
The following code:
Gives me:
This is a correct z3 expression. It can be solved through z3 CLI utility. But for some reasons it gives me z3: ast is not an expression in C++ code. This is interesting, probably another bug in z3 API?
I have been trying to debug the exception "ast is not an expression"....
For information; here is a minimal code (b2.c):
Cppcheck output for me (in ubuntu 20.10):
Here is the exception!!
The z3 expressions is a debug output I added in the
BinaryResult::isEqual
method.This is an stripped down C++ code that should use the Z3 library in a very similar way as Cppcheck did:
When I compile and run that stripped down code I get no exception..
The Z3 output is identical as far as I can tell.. so why doesn't it work in Cppcheck. Any wild guesses?
Last edit: Daniel Marjamäki 2020-12-21
I'm still unable to get to my linux computer to test. Below is the rough version of a bash script I used on centos 7 to build cppcheck and z3. I know I have the devtoolset-9 installed.
Does cppcheck get the exception with z3-4.4.1? When I get a chance it's not to hard for me to build other tagged versions of z3. I can always gdb into z3 and try and back solve from the exception.
Not sure about 4.4.1, but I get this exception with upstream z3 built from sources (commit *
28a6da4532c952a7077d233421aa498f5ca2ff59). The backtrace leads to check_error* call inside get_sort function for the result expression. I haven't looked deeper yet, but it seems, that something goes wrong in C part of z3 sources.
I have figured out that Z3 does not like when float and int is mixed.
I don't know if a z3::expr that is int can be promoted to float. There is a "z3::to_real" but no "z3::to_fpa" as far as I see.
We need to tweak ExprData and that part somehow. But we also need to update inputs. If you write this code:
ValueRangeHigh(100) double doubleHighTest;
Then Cppcheck must convert that to a float somewhere! Right now the Cppcheck attribute is an int so it will not handle an upper limit 123.45 well..
One thing I was thinking might be useful is units. ValueUnit("miles per hour") It would allow for the possiblity of add maybe a limits file. So you can uses the speed of light or speed of sound for miles per hour. For temperatures you could use the melting point of tungsten. I could see this being useful for bug hunting in a use case where someone says my program should have no speeds faster than the speed of sound. It would make better constraints than max size of a double.
I have also thought about defining units somehow. It sounds cool.
https://github.com/Unidata/UDUNITS-2
what I have thought about is to detect mistakes.
for instance conversion mistakes:
or if we detect some arithmetic with incompatible units:
expression1 [milliseconds] + expression2 [nanoseconds]
we can warn about that too.How the units for variables and constants should be defined.. I don't know.
I think this addon will check for such mistakes: https://github.com/unl-nimbus-lab/phriky-units
it sounds very promising but I haven't looked at it closely.
That looks very interesting.
It is interesting the python and C API seem to have those type of functions.