`evm run --bench` segfaults in `Fatalf`

[xermicus]

The following command:

evm run --bench --nomemory=false --noreturndata=false --codefile - --prestate /tmp/genesis.json --sender 0000000000000000000000000000000000000000 --input cde4efa9

/tmp/genesis.json:

{
    "config": {
        "chainId": 420420420,
        "homesteadBlock": 0,
        "eip150Block": 0,
        "eip155Block": 0,
        "eip158Block": 0,
        "byzantiumBlock": 0,
        "constantinopleBlock": 0,
        "petersburgBlock": 0,
        "istanbulBlock": 0,
        "berlinBlock": 0,
        "londonBlock": 0,
        "arrowGlacierBlock": 0,
        "grayGlacierBlock": 0,
        "shanghaiTime": 0,
        "cancunTime": 0,
        "terminalTotalDifficulty": 0,
        "terminalTotalDifficultyPassed": true
    },
    "coinbase": "0x0000000000000000000000000000000000000000",
    "difficulty": "0x20000",
    "extraData": "",
    "gasLimit": "0xffffffff",
    "nonce": "0x0000000000000042",
    "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "timestamp": "0x00",
    "alloc": {
        "0101010101010101010101010101010101010101": {
            "balance": "1000000000"
        },
        "0202020202020202020202020202020202020202": {
            "balance": "1000000000"
        },
        "0303030303030303030303030303030303030303": {
            "balance": "1000000000"
        }
    }
}

Fixture: 6080604052348015600e575f80fd5b50600436106026575f3560e01c8063cde4efa914602a575b5f80fd5b60306032565b005b5f8054906101000a900460ff16155f806101000a81548160ff02191690831515021790555056fea264697066735822122046c92dd2fd612b1ed93d184dad4c49f61c44690722c4a6c7c746ebeb0aadeb4a64736f6c63430008190033

Results in:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xd205a0]

goroutine 59 [running]:
testing.(*common).decorate(0x20?, {0xc0002d0080, 0x20}, 0xc000300008?)
    testing/testing.go:775 +0xa0
testing.(*common).logDepth(0xc00036f408, {0xc0002d0080, 0x20}, 0x3)
    testing/testing.go:1042 +0x1dc
testing.(*common).log(...)
    testing/testing.go:1011
testing.(*common).Fatalf(0xc00036f408, {0x140c196?, 0x140aa06?}, {0xc00002ff20?, 0xc00002ff00?, 0x2?})
    testing/testing.go:1089 +0x54
main.timedExec.func1(0xc00036f408)
    github.com/ethereum/go-ethereum/cmd/evm/runner.go:97 +0x2ea
testing.(*B).runN(0xc00036f408, 0x1)
    testing/benchmark.go:193 +0xf0
testing.(*B).run1.func1()
    testing/benchmark.go:215 +0x48
created by testing.(*B).run1 in goroutine 1
    testing/benchmark.go:208 +0x90

The bug is introduced with this PR: https://github.com/ethereum/go-ethereum/pull/30442/files#diff-48d6c3d5b7c9c1d0bd83fa0d5ac8fe38ce3ce34aaf39f22d00e84fcf61b249b4

The lines in the stack trace do seem off too.

[xermicus]

FYI the older versions not in the PPA, there are no evm binaries provided and there is no 1.14.11 release branch. So anyone hitting a bug in the latest release is supposed to manually bisect the codebase to find a working commit and install it on their own? This can't be it, or how would anyone get an older release installed?

[jwasinger]

--codefile - - this part seems wrong? If I put the name of the code file, the benchmark runs fine on my machine.

[jwasinger]

However, if I omit the name of the code file (and just put a - as you did), the execution spins forever for me....

[xermicus]

The evm cmd help says:

    --codefile value                                                      
          File containing EVM code. If '-' is specified, code is read from stdin

[jwasinger]

Ah, I was referencing the wrong evm binary. Yes, I can reproduce the crash locally.

[xermicus]

However, if I omit the name of the code file (and just put a - as you did), the execution spins forever for me....

evm run --bench --nomemory=false --noreturndata=false - --prestate /tmp/genesis.json --sender 0000000000000000000000000000000000000000 --input cde4efa9 open -: no such file or directory

This doesn't seem right and contradicts the help. Also it used to work in the previous version :) To me it seems like a bug

[xermicus]

Ah, I was referencing the wrong evm binary. Yes, I can reproduce the crash locally.

Ah right, thanks for looking into it!