-
Notifications
You must be signed in to change notification settings - Fork 2
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
Checking validity of heap object concretisation (p'obj.next). #1
Comments
Is there any easy way how to print out the resulting ssa form of program? |
If we checked only the last definition of p wouldn't it be a problem in the following case: Couldn't this lead to the unsoundness the we have experienced before? |
you can print the ssa using local_SSAt::output function |
in that case since p->next was not defined before when first used, it would not be transformed into p'obj.next, but into approriate dynamic_object.next |
OK and when we define it? p = malloc(); |
then we probably would, yes I think this is a conceptual problem - dynamic_object is an abstraction and thus it might not cover all options in combination with the SSA form that we use maybe we could solve this by defining p'obj.next in case it has not been defined since last assignment to p - we could get the value to be assigned to p'obj.next from dereferencing p - this way we would have p'obj.next as a concretised object which is assigned all possible values of actual abstract dynamic_objects that p might point to |
So we would concretise p'obj.next to all possible values which p->next may have? I think about another solution. Could not we stay with the current state but create for each point p set of the dependent objects P={p'obj.sel | sel is from set of all selectors of p}. Then once p is defined we invalidate all objects from P. Would this work? |
That would work but in the last example you provided, you would invalidate p'obj.next for p = ...; and thus when transforming x = p->next, you can't use p'obj.next (since it is invalidated) and you have to use dynamic_object.next, which might again bring unsoundness. I definitely agree with the idea of having dependent objects, but I think we will also have to introduce a mechanism to "concretise" object when reading it (when it appears on the right hand side) because currently we do that when it is written. |
@martinhruska, can you please paste here the current SSA as produced by the tool for your example above (fill in the ... with something that makes sense)? |
So consider the following (a little bit artificial :) C code:
The following SSA form is produced:
|
Ok, so, removing unnecessary stuff, we have:
|
The described problem should be solved by pull request #3. However, we will probably need to concretize also the dereferences in assertions to make the analysis more precise. |
currently, we transform an assignment with memory access at right hand side into SSA as follows:
a = p->next (original assignment in C/GOTO program)
a#cur-loc == p'obj.next#last-loc (SSA equality where cur-loc is the current location and last-loc is the location of the last assignment of p'obj.next)
this transformation is done by method local_SSAt::build_transfer
we check whether p'obj.next has been defined before (function all_symbolic_deref_called at line 469 in local_ssa.cpp)
but we also need to check whether p has not changed since last assignment of p'obj.next, because that would make p'obj.next invalid
in that case, we would have to use actual abstract object on the heap (dynamic_object$0.next) instead - this can be obtained by calling the function local_SSAt::dereference on p->next
I'd suggest including this check into build_transfer function
maybe it would be enough to check whether last definition of pointer p is before the last definition o p'obj.next - this information can be retrieved from ssa_analysis, for inspiration see all_symbolic_deref_defined (question is, is this really sound?)
retrieving pointer p from object p'obj should be possible using functions from ssa_pointed_objects.h, particularly get_pointer
merge into heap branch
The text was updated successfully, but these errors were encountered: