trailofbits / manticore

Symbolic execution tool
https://blog.trailofbits.com/2017/04/27/manticore-symbolic-execution-for-humans/
GNU Affero General Public License v3.0
3.7k stars 471 forks source link

Contract creation silently fails because of contract size #1477

Open VeraBE opened 5 years ago

VeraBE commented 5 years ago

OS / Environment

Distributor ID: LinuxMint Description: Linux Mint 18.3 Sylvia Release: 18.3 Codename: sylvia

Manticore version

Version: 0.3.0

Python version

Python 3.6.5 :: Anaconda, Inc.

Summary of the problem

Contract creation fails without a message, it just gets stuck in manticore.solidity_create_contract.

Step to reproduce the behavior

Call manticore.solidity_create_contract with:

contract TestSizeManticore {

    function aFunction() public pure returns(int) {
        int aVar = 0;

        aVar = aVar + 1;
        aVar = aVar + 1;
        aVar = aVar + 1;
        aVar = aVar + 1;
        ... (the same line must be repeated 1782 times)
        aVar = aVar + 1;

        return aVar;
    }
}

If I comment the last assignment it does work. I thought it might be a gas issue so I tried to call it with 100000 more gas than the default value but it doesn't work either.

feliam commented 5 years ago

Not able to reproduce so far. I'm using

solc, the solidity compiler commandline interface
Version: 0.4.24+commit.e67f0147.Linux.g++

with something like this...

import pyevmasm 
from manticore.ethereum import ManticoreEVM
m = ManticoreEVM()
user=m.create_account()
contract = m.solidity_create_contract(source_code, owner=user)
for st in m.all_states:
    print ("contract address:", hex(int(contract)))
    bcode = st.solve_one(st.platform.get_code(int(contract)))
    for i in pyevmasm.disassemble_all(bcode):
        print (hex(i.pc), i)
VeraBE commented 5 years ago

I'm using 0.4.21 for this.

Maybe is a memory related issue? Maybe if you add more assignments it crashes in your machine?

verabe@ThinkPadT470 ~ $ free -m
              total        used        free      shared  buff/cache   available
Mem:          15792        5035        1812         636        8944        9662
Swap:          7628         877        6751
verabe@ThinkPadT470 ~ $ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 62628
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 62628
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
feliam commented 5 years ago

Okay, 17810 aVar = aVar + 1; did it for me. It looks like the a worker eats all memory, dies, and fails to report it to the main manticore so it diverges or gets deadlocked. (guessing)

moodysalem commented 4 years ago

I have a large contract I am testing with echidna (echidna can now support virtually unlimited contract size after https://github.com/crytic/echidna/issues/531), and it would be great if this also worked in manticore. It seems like my test process just never exits