Skip to content

Incremental unwinding of one specified loop -- rebase #5217

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

Merged
merged 20 commits into from
Feb 11, 2020

Conversation

xbauch
Copy link
Contributor

@xbauch xbauch commented Jan 27, 2020

Incremental unwinding and assertion checking of a specified loop.

This is a rebase of #4361.

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@codecov-io
Copy link

codecov-io commented Jan 27, 2020

Codecov Report

Merging #5217 into develop will increase coverage by 0.07%.
The diff coverage is 92.71%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #5217      +/-   ##
===========================================
+ Coverage    67.43%   67.51%   +0.07%     
===========================================
  Files         1157     1161       +4     
  Lines        95351    95495     +144     
===========================================
+ Hits         64303    64476     +173     
+ Misses       31048    31019      -29
Flag Coverage Δ
#cproversmt2 42.59% <8.6%> (-0.09%) ⬇️
#regression 64.04% <92.71%> (+0.08%) ⬆️
#unit 31.9% <6.62%> (-0.06%) ⬇️
Impacted Files Coverage Δ
src/goto-symex/goto_symex.h 91.66% <ø> (ø) ⬆️
src/goto-symex/symex_target_equation.h 92.3% <ø> (ø) ⬆️
src/goto-symex/symex_main.cpp 87.74% <100%> (ø) ⬆️
src/goto-symex/symex_goto.cpp 96.6% <100%> (+0.05%) ⬆️
...to-checker/single_loop_incremental_symex_checker.h 100% <100%> (ø)
src/goto-checker/symex_bmc_incremental_one_loop.h 100% <100%> (ø)
src/goto-checker/goto_symex_property_decider.cpp 100% <100%> (+3.22%) ⬆️
src/goto-symex/symex_target_equation.cpp 95.69% <85.71%> (+0.52%) ⬆️
src/cbmc/cbmc_parse_options.cpp 75.65% <89.47%> (+0.58%) ⬆️
...-checker/single_loop_incremental_symex_checker.cpp 92.1% <92.1%> (ø)
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5b4bcc6...eebfcd9. Read the comment docs.

@xbauch xbauch changed the title [CI-TEST] Incremental one loop rebase Incremental unwinding of one specified loop -- rebase Jan 27, 2020
@hannes-steffenhagen-diffblue
Copy link
Contributor

@tautschnig Were your comments from #4361 addressed?

Copy link
Contributor

@thk123 thk123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments from @tautschnig on original PR that are still outstanding

: 0)
{
ignore_assertions =
options.get_bool_option("ignore-properties-before-unwind-min");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a question for @peterschrammel

When was this option introduced and where is it documented?

#4361 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been introduced as part of this PR. Maybe it hasn't been documented as part of thIs PR, though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
options.get_bool_option("ignore-properties-before-unwind-min");
incr_min_unwind >= 2 && options.get_bool_option("ignore-properties-before-unwind-min");

@peterschrammel or at least this way it was in 5.4.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any observable effect of adding this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well since the test(s) in question do not set the unwind-min I assume it is 1 by default. So the ignoring would not even occur. So yes, the test passes, but rather trivially.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, the test is still wrong if you set the unwind-min (to 10 for example) even with the suggested change.

@thk123
Copy link
Contributor

thk123 commented Jan 29, 2020

Niavely looking at coverage we should add the following tests:

  • a pretty shortest trace (e.g. with --beautify turned on for one of the tests)
  • building a non-shortest trace for a property
  • building a full trace

(dunno how you exercise those last two options)

Also, we should add a trivial test for checking exit with non-zero exit code if ran with --paths as well as --incremental-loop just to stop any boneheaded mistakes in future

Also, less nit picky, but it seems like symex_bmc_incremental_one_loopt is not tested with any loop_unwind_handlers. This seems like it should be added

Cannot be used with incremental loop unwinding.
not 'ignore' (which is used for slicing).
Allows ignoring assertions until a certain condition
is satisfied (e.g. a certain unwinding is reached).
Used for implementation of ignore-assertions-before-unwind-min.
This enables the caller to handle assertion conversion differently,
e.g. for incremental loop unwinding.
We can ignore already failed properties.
Required for incremental loop unwinding.
Implement callback that decides on when to interrupt
goto-symex during incremental unwinding.
Checks the assertions after each iteration of
a specified loop.
for incremental unwinding and assertion checking
of a specified loop.
for incremental unwinding and assertion checking
of a specified loop.
Otherwise single quotes get incorrectly stripped off.
This seems to work when calling bash again. Otherwise,
we can get something like:

This is half a liEXIT=123
Option name has changed.
These require more options that have not been implemented yet.
Allows to check assertions only between unwind-min and unwind-max
iterations of a specified loop.
@xbauch xbauch force-pushed the incremental-one-loop-rebase branch 2 times, most recently from 46dad61 to 3bcb5ff Compare January 29, 2020 16:36
Copy link
Contributor

@thk123 thk123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT all of @tautschnig comments from #4361 have been addressed.

/// \param unwind: current unwinding counter
/// \return true if the symbolic execution is to be interrupted for checking
virtual bool check_break(
const irep_idt &id,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⛏️ is this the loop id? given how frequent ids are used in this code base, I'd probably call it loop_id

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@xbauch
Copy link
Contributor Author

xbauch commented Jan 29, 2020

  • a pretty shortest trace (e.g. with --beautify turned on for one of the tests)

It seems that the refinement solver does not support beatification

@xbauch
Copy link
Contributor Author

xbauch commented Jan 29, 2020

  • a pretty shortest trace (e.g. with --beautify turned on for one of the tests)
  • building a non-shortest trace for a property
  • building a full trace

I have a suspicion that some of the build_*trace functions are only there to override the default and cannot really be called in any of our factory-produced verifiers. I'll keep digging.

@xbauch xbauch force-pushed the incremental-one-loop-rebase branch from 3bcb5ff to efd8ffe Compare January 30, 2020 16:21
`check_break` is now documented in `goto_symex.h` as well (I removed the
parameters that were not used anywhere).
@xbauch xbauch force-pushed the incremental-one-loop-rebase branch from efd8ffe to 6db9447 Compare January 30, 2020 17:01
@xbauch
Copy link
Contributor Author

xbauch commented Jan 31, 2020

@peterschrammel In an attempt to improve coverage, the last commit adds a test for trace production. I've also suggested commenting out the implementation of the "beautified" trace and the "full" trace since I don't think they can be exercised by any of the current verifier combinations. Is it change acceptable?

goto_trace);

return goto_trace;
UNREACHABLE;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚫 Write a test for it if you want to cover it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@xbauch xbauch force-pushed the incremental-one-loop-rebase branch from 6db9447 to d91d9d9 Compare February 4, 2020 10:47
1: working test for the standard trace.
2: failing test for the beautified shortest trace.
@xbauch xbauch force-pushed the incremental-one-loop-rebase branch from d91d9d9 to 39c5ac8 Compare February 4, 2020 10:49
@xbauch xbauch requested a review from peterschrammel February 4, 2020 10:49
@@ -0,0 +1,14 @@
int main()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⛏️ typo in commit message KNOWBUG -> KNOWNBUG

--
^warning: ignoring
--
This will fail the invariant on `build_goto_trace.cpp:320` asserting certain
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you raise a bug on cbmc and put the issue number here.

^VERIFICATION FAILED$
^State \d+ file main.c function havocIO line 501 thread \d+$
--
^warning: ignoring
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A description of why you added this test (e.g. tests the trace production for ??)

@thk123
Copy link
Contributor

thk123 commented Feb 4, 2020

Maybe you already knew this, but the key flag is --ignore-properties-before-unwind-min, disabling that causes it to find the failure


while(1)
{
__CPROVER_assume(property == 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of the unused assumption variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hard to say, but if you comment it out, it suddenly starts to work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean the assumption variable, not the assumption statement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, yes, that one is irrelevant.

@xbauch xbauch force-pushed the incremental-one-loop-rebase branch from 3e2ad1c to dff27a3 Compare February 5, 2020 14:40
Basically, if unwind-min is zero (by default) the first loop iterations should
not be ignored (even if requested). Tests show the problem.
@xbauch xbauch force-pushed the incremental-one-loop-rebase branch from dff27a3 to eebfcd9 Compare February 5, 2020 14:42
@xbauch
Copy link
Contributor Author

xbauch commented Feb 5, 2020

@peterschrammel I've added the check for when to start ignoring properties (eebfcd9) and cleaned up the test.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this branch has the history I think it does it might be a candidate for the longest running branch as it predates even VSD!

@thk123
Copy link
Contributor

thk123 commented Feb 7, 2020

Just noting the travis job has passed, but for some reason the icon has not refreshed on here

^Unwinding loop main\.3 iteration 3
--
^warning: ignoring
^Unwinding loop main\.0 iteration 6
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing new line at end of file

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed (I had to rerun the CI anyway).

to a test description file.
@xbauch xbauch merged commit d51243d into diffblue:develop Feb 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants