0

I am testing simple ERC20 token creation with the following in remix:

pragma solidity ^0.5.0;

import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Detailed.sol";

contract TestToken is ERC20, ERC20Detailed {

    constructor () public ERC20Detailed("TestToken", "TKN", 18) {
        _mint(msg.sender, 1000000 * (10 ** uint256(decimals())));
    }
}

I launch the contract and debug, but prior to every JUMP opcode, i receive an INVALID opcode in remix debugger.

If we look at _mint call in the stack trace (opcode 250 on compiler 0.5.13): 

PUSH1 20
INVALID
JUMP
JUMPDEST

Is this merely a parse error or is every jump have an invalid opcode now? How can one discern this from an OPCODE used as an error?

| improve this question | |
0

I had a quick look - the INVALID instruction is 0x1C which is SHR or bitwise shift right. This was added in the Constantinople hard fork in February of this year (EIP145). My guess is that the Remix debugger hasn't been updated to include this instruction.

| improve this answer | |
  • Dont INVALID opcodes trigger the exception throwing in the EVM? I thought the original throw was just an invalid opcode – user462003 Nov 27 '19 at 19:58
  • They do. But the point here is that I suspect that it's not an INVALID opcode in this particular case - I went and looked at the actual assembly - it's just that the Remix debugger doesn't understand what it is because it changed recently, and needs to be updated – Zakalwe Nov 28 '19 at 14:25
  • Yup i get it, thanks. I guess if we are performing tracing, you have to ensure the latest compiler version to prevent INVALID opcodes creating false scenarios. – user462003 Nov 28 '19 at 23:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.