-
Notifications
You must be signed in to change notification settings - Fork 273
Do not assign to objects that have gone out of scope #1116
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CBMC seems to lose its capability with this patch to propagate some constants and deduce loop bounds. See local_out_of_scope5.c:
void f(int size) {
for(int i=0; i<size; ++i);
}
void main(void)
{
f(1);
__CPROVER_assert(0==1, "");
}
src/goto-symex/symex_goto.cpp
Outdated
// do not merge when we don't have a local symbol in the goto | ||
// state; those should have been filtered out already in | ||
// goto_symext::symex_assign_symbol | ||
CHECK_RETURN(l2!=0 || it->get_level_1().empty()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This assertion gets violated with local_out_of_scope4.c:
extern int OPCODE;
void f(int *opcode) {
if(*opcode==0)
int *opcode_trace=opcode;
else
__CPROVER_assume(0==1);
}
void main(void)
{
f(&OPCODE);
__CPROVER_assert(0==1, "");
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it seems I've got quite a bit more work to do here. I've figured out some of the cases (function parameters), with others still to be done. My apologies that this is taking much longer than expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My apologies for dragging up such obscure use cases ;-) . Unfortunately the CEGIS module applies arrays of pointers in a lot of scenarios.
Pointer dereferencing may yield objects that have meanwhile gone out of scope. Assigning to them is unnecessary, and performing a merge on those would yield inconsistent equations (as witnessed by the included regression test). Filtering out the merge in phi nodes is not easily possible as there are several cases where it is permissible that only one of the states entering the phi node has an (L1) object, such as declarations only seen in one branch. Fixes: diffblue#1115
I hope to have addressed all failures in this updated version of the patch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm that all use cases I tested it with work now.
Pointer dereferencing may yield objects that have meanwhile gone out of scope.
As an optimisation, assigning to them is unnecessary. It is, however, essential
not to perform a merge when only one of the states entering the phi node
actually has an (L1) object. The optimisation guarantees that the latter does
not happen.
Fixes: #1115