Execution of impossible paths during verification #2124
Labels
performance
Issues that involve or include performance problems
subsystem: crucible-mir
Issues related to Rust verification with crucible-mir and/or mir-json
tech debt
Issues that document or involve technical debt
type: bug
Issues reporting bugs or unexpected/unwanted behavior
Milestone
In the course of Formal VerSo work I ran into some cases where apparently impossible paths were executed during verification leading to hitting
error
in one of the Cryptol models. I have now cut down the Formal VerSo material to a (relatively) small example that still fails, as follows.First, the ever-popular test.rs:
Then, test.saw:
and finally, Test.cry:
When run (
saw test.saw
) this produces the following output:Observe that there's only the one call to
error
anywhere in here, and while that has two call sites they're next to each other and equivalent, so it's clear where it must be going. (That's on lines 152-153 of Test.cry.)HOWEVER, that code should be unreachable: the only cases in which
lookup_vec
producesnone
are the same cases wherepresent_as_vec
producesFalse
.Furthermore (though it's not as easily inspected) this whole enclosing case should not be reached either because the type tags on both values that are being compared are constrained to be
tag_symbolsmall
which is less thansmall_tag_upper_bound
. So it should always take the path on line 144.If you replace the
crashing_unwrap
with something that doesn't crash, as you can do by uncommenting what's on lines 154-155, then saw runs forever inspecting garbage heap states without any indication that it's spending that time investigating impossible executions. (Although it shouldn't do that either -- because the default value produced is an empty vector the comparison of those should terminate immediately instead of recursing into arbitrary other comparisons.) This is why I've marked it a performance problem.I have no idea if it's possible to trigger unsoundness via whatever's going on. One would hope the worst that executing impossible paths could cause is spurious counterexamples rather than accepting invalid propositions.
The text was updated successfully, but these errors were encountered: