Skip to content

Commit

Permalink
Use invalid init code on colission
Browse files Browse the repository at this point in the history
  • Loading branch information
@rmeissner
rmeissner committed Oct 17, 2018
1 parent 0fa1bda commit b549fdb
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion lib/runCall.js
View file
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,9 @@ module.exports = function (opts, cb) {
}

if ((account.nonce && new BN(account.nonce) > 0) || account.codeHash.compare(EMPTY_CODE_HASH) !== 0) {
done(ERROR.INVALID_OPCODE)
toAccount = account
code = new Buffer("0xfe", "hex") // Invalid init code
done()

This comment has been minimized.

Sign in to view

Copy link
@holgerd77

holgerd77 Oct 17, 2018

Member

Oh, that looks like creative experimentation? 👍 Cool that you are keeping on with this.

This comment has been minimized.

Sign in to view

Copy link
@rmeissner

rmeissner Oct 17, 2018 •
edited
Loading

Author Contributor

Yeah I wanna use it :D But there is still have a lot to learn regarding tests for ethereum clients.

What I figured out was, that if I use done(ERROR.INVALID_OPCODE) it uses up all available gas. While (as you pointed out on gitter) an invalid code in the init code just sets the return value to 0.

So the failing tests are because of gas issues, but I still don't know the exact amount that is off.

This comment has been minimized.

Sign in to view

Copy link
@holgerd77

holgerd77 Oct 17, 2018

Member

If you learn stuff about testing and see that this is not documented it would also be great if you directly do a PR over on the test repo at https://github.com/ethereum/tests, this is very much needed and will help others a lot!

This comment has been minimized.

Sign in to view

Copy link
@holgerd77

holgerd77 Oct 17, 2018

Member

(so a PR towards the docs in the docs/ directory or eventually directly on the README file)

This comment has been minimized.

Sign in to view

Copy link
@rmeissner

rmeissner Oct 17, 2018 •
edited
Loading

Author Contributor

For me the biggest challenge is to figure out what the expected state is. Some things can be figured out from the pre and post states in the test and filler jsons. But others are quite hard to see (since you only get the message that the state root is not as expected)

Actually using testeth would work for that, but I think there are some changes required in the repo.

I am taking notes, so I will check if I can add something to the docs once I get it to work ;)

This comment has been minimized.

Sign in to view

Copy link
@holgerd77

holgerd77 Oct 17, 2018

Member

You can also can use trace information from the VM with the --jsontrace flag (see README) which will a trace of all opcodes and state of stack, memory and then compare it to the output from some other client, see also a related issue here #351.

TBH I am currently also not sure what is the easiest way to do that though and what client would be recommendable for that, I sometime ago did that with the old and now outdated pyethereum implementation, maybe Py-EVM would now be a good candidate, not sure.

@jwasinger is the expert on this front, maybe he can also give some hints.

This comment has been minimized.

Sign in to view

Copy link
@rmeissner

rmeissner Oct 17, 2018

Author Contributor

yeah the interesting part for me is to have a reference to the "correct" values. I could probably use geth (I have a local version of that :D ).
return
}

Expand Down

0 comments on commit b549fdb

Please sign in to comment.