You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The result shows that, although the function foo and bar are exactly the same, the validity check of v failed in the function foo but not in bar. This is the report
** Results:
assign.c function bar
[bar.1] line 13 Check loop invariant before entry: SUCCESS
[bar.2] line 13 Check that loop invariant is preserved: SUCCESS
[bar.3] line 13 Check that loop instrumentation was not truncated: SUCCESS
[bar.assigns.2] line 13 Check that i is valid: SUCCESS
[bar.assigns.3] line 13 Check that i is assignable: SUCCESS
[bar.assigns.1] line 14 Check that v is valid: SUCCESS
assign.c function foo
[foo.1] line 4 Check loop invariant before entry: SUCCESS
[foo.2] line 4 Check that loop invariant is preserved: SUCCESS
[foo.3] line 4 Check that loop instrumentation was not truncated: SUCCESS
[foo.assigns.2] line 4 Check that i is valid: SUCCESS
[foo.assigns.3] line 4 Check that i is assignable: SUCCESS
[foo.assigns.1] line 5 Check that v is valid: FAILURE
The validity check checks if v is a dead object, i.e.,
The check happens before the loop body where v is declared. When the abstracted loop is executed for the first time, v is undeclared and not dead, which is the reason why the check success in bar. At the end of the first abstracted loop, v will be dead and set to be a dead object
// 49 file assign.c line 5 function foo
ASSIGN __CPROVER_dead_object := (side_effect statement="nondet" is_nondet_nullable="1" ? cast(address_of(foo::1::1::1::v), empty*) : __CPROVER_dead_object)
// 50 file assign.c line 5 function foo
DEAD foo::1::1::1::v
Therefore, at the second time we execute the loop, v is not re-declared yet and is dead, that is why the check failed in foo.
A possible fix is not to check validity of local variables at the beginning of loops. @remi-delmas-3000 Do you have any thoughts
The text was updated successfully, but these errors were encountered:
qinheping
changed the title
Validy checks fail for local variables when abstracted loops are excted more than one time
Validity checks fail for local variables when abstracted loops are excted more than one time
Jun 17, 2022
qinheping
changed the title
Validity checks fail for local variables when abstracted loops are excted more than one time
Validity checks fail for local variables when abstracted loops are executed more than one time
Jun 17, 2022
Uh oh!
There was an error while loading. Please reload this page.
CBMC version: 5.59.0
Operating system: macOS 12.3.1
Exact command line resulting in the issue:
I ran the above command lines on the following c program
The result shows that, although the function
foo
andbar
are exactly the same, the validity check ofv
failed in the functionfoo
but not inbar
. This is the reportThe validity check checks if
v
is a dead object, i.e.,The check happens before the loop body where
v
is declared. When the abstracted loop is executed for the first time,v
is undeclared and not dead, which is the reason why the check success inbar
. At the end of the first abstracted loop,v
will be dead and set to be a dead objectTherefore, at the second time we execute the loop,
v
is not re-declared yet and is dead, that is why the check failed infoo
.A possible fix is not to check validity of local variables at the beginning of loops. @remi-delmas-3000 Do you have any thoughts
The text was updated successfully, but these errors were encountered: