-
Notifications
You must be signed in to change notification settings - Fork 274
natural_loop
s not computed correctly in presence of function pointers [blocks #5530]
#6168
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
Comments
natual_loop
s not computed correctly in presence of function pointersnatural_loop
s not computed correctly in presence of function pointers
cc. @chrisr-diffblue |
That's horrible :-\ Conjecture : your problem is here: Line 397 in 0ae6010
Fixing it at the source is ... going to be unpleasant, ironically for the same reason that this bug happened in the first place. It is not clear what the "correct" or "normal" form(s) for `goto_modelt` are. Various passes make assumptions about what other passes have or haven't been run. These are not documented or enforced and mainly result in wrong results rather than errors. Cleaning this up is going to be a big job. The changes to `process_goto_program` were to try to normalise this a bit but did result in a couple of bits of weird behaviour. I haven't started on `goto-instrument` yet because it probably has the largest amount of 'variety' in what does and doesn't get run. Like fixing how function pointers are handled, it's on my TODO list but unless someone wants to pay me, it's not going to happen immediately.My suggested work-around is to insert calls to |
Joining this conversation with some delay. @martin-cs Many thanks for root causing this! While I agree that "normal" form(s) aren't properly defined for now, we should review why |
My guess (not recalling that I had worked on this!) is that the edge computation is general purpose and interprocedural and used for many things and natural loop computation just uses that without really thinking about the consequences. |
natural_loop
s not computed correctly in presence of function pointersnatural_loop
s not computed correctly in presence of function pointers [blocks #5530]
This fixes the infinite unwinding by adding calls to `do_indirect_call_and_rtti_removal()` before the contracts code invocation in `goto-instrument/`.
This fixes the infinite unwinding by adding calls to `do_indirect_call_and_rtti_removal()` before the contracts code invocation in `goto-instrument/`.
This also demonstrates the issue being fixed.
This fixes the infinite unwinding by adding calls to `do_indirect_call_and_rtti_removal()` before the contracts code invocation in `goto-instrument/`.
This also demonstrates the issue being fixed.
Add workaround for issue described in #6168.
It looks like the issue should be worked around using @martin-cs' suggestion after the merge of #6340 . Let us know if this has been fixed adequately for your use case, or if we need to be doing something more. |
@SaswatPadhi, can you confirm this works now. And, if so, close the ticket. |
The fix seems to work for the loop contracts I added to Thanks @NlightNFotis and @martin-cs! |
Uh oh!
There was an error while loading. Please reload this page.
CBMC version: 556b432
Operating system: Mac OS 10.15.7
Test case:
Exact command line resulting in the issue:
What behaviour did you expect:
The loop invariant would be used and unwinding wouldn't be necessary.
What happened instead:
The loop invariant is not used because the loop in
main
is not recognized.Note that if we use
adder
in place oflocal_adder
within the loop, then the loop is detected and the loop invariant is processed as expected.Additional context:
If we use
adder
in place oflocal_adder
above, i.e. call the function directly as opposed to using a function pointer, then loop is detected and invariant is processed as expected.The following instrumentation code:
produces the following output when using
local_adder
function pointerand produces the following output when using
adder
directlyThe text was updated successfully, but these errors were encountered: