Assertion Checking Modes
There are several options for what Scribble can do when an assertion fails. By default Scribble will emit an assert (false)
and an additional log statement emit AssertionFailed("..")
. For example, given this annotated code:
The instrumented code would look like this:
The emit AssertionFailed("0: P1")
statement on line 7 is used to signal to tools such as Mythril and Harvey that a user property violation was found . It can be also useful for the end user to identify which property failed in normal test runs by looking at the emitted events.
No assertions
Sometimes for long running tests and fuzzing campaigns we don't want to interrupt the tests for every violation found. In those cases you can prevent scribble
from emitting assert(false)
with the --no-assert
option.
User assertion failures without event logging
In some cases signaling a user property violation using event logging may be inconvenient, since the assertion failure check may occur in a view
function. In such cases adding an emit
statement changes the mutability of the instrumented function, which can change the interfaces of the compiled contracts and may break tests. For this reason scribble
(and Mythril and Harvey) support an alternative mode for signaling custom property violations using memory stores with specially crafted bit-strings. You can select this mode with the --user-assert-mode mstore
command line option. If you were to instrument our earlier exmaple in this mode the instrumented code would look as such:
In this mode the assertion failure is signaled by the store to _v.__mstore_scratch__
on line 12. Tools such as Myhtril and Harvey can watch for assignments to memory with the 0xcafe
pattern appended with the id of the failing assertion.
Last updated