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:
1
contract Foo {
2
    /// #if_succeeds {:msg "P1"} y == x + 1; 
3
    function inc(uint x) public pure returns (uint y) {
4
        return x+1;
5
    }
6
}
Copied!
The instrumented code would look like this:
1
contract Foo {
2
    event AssertionFailed(string message);
3
​
4
    function inc(uint x) public returns (uint y) {
5
        y = _original_Foo_inc(x);
6
        if ((!((y == (x + 1))))) {
7
            emit AssertionFailed("0: P1");
8
            assert(false);
9
        }
10
    }
11
​
12
    function _original_Foo_inc(uint x) private pure returns (uint y) {
13
        return (x + 1);
14
    }
15
}
Copied!
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:
1
contract Foo {
2
    struct vars0 {
3
        uint256 __mstore_scratch__;
4
    }
5
​
6
    function inc(uint x) public pure returns (uint y) {
7
        vars0 memory _v;
8
        y = _original_Foo_inc(x);
9
        {
10
            _v.__mstore_scratch__ = 0xcafecafecafecafecafecafecafecafecafecafecafecafecafecafecafe1000;
11
            if ((!((y == (x + 1))))) {
12
                _v.__mstore_scratch__ = 0xcafecafecafecafecafecafecafecafecafecafecafecafecafecafecafe0000;
13
                assert(false);
14
            }
15
        }
16
    }
17
​
18
    function _original_Foo_inc(uint x) private pure returns (uint y) {
19
        return (x + 1);
20
    }
21
}
Copied!
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.

Arm and disarm

Next - Tool

Instrumented Code

Last modified 2mo ago

Copy link

Contents

No assertions

User assertion failures without event logging