How to detect what instruction caused “truffle test” to result in “invalid opcode” error?

Question

I wrote a test for my contract and it returns invalid opcode as a result. Full output:

1) Contract: FPCoin1 One can purchase tokens for ether:
 Error: VM Exception while processing transaction: invalid opcode
  at Object.InvalidResponse (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:37312:16)
  at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:220420:36
  at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:204149:9
  at XMLHttpRequest.request.onreadystatechange (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:205574:13)
  at XMLHttpRequestEventTarget.dispatchEvent (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:73069:18)
  at XMLHttpRequest._setReadyState (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:73359:12)
  at XMLHttpRequest._onHttpResponseEnd (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:73514:12)
  at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:73474:24)

It tells me no particular information which instruction or line caused the problem. Is it possible to actually see what went wrong?

Answer 1

You can’t really get much feedback from a truffle test if an error is thrown from within a function’s execution.

You can do some simple quick checks to verify you have provided valid arguments to the function, such as double checking any require, assert, or any reverts anywhere and figuring out what’s getting passed in. Also if there are any modifiers (eg onlyOwner or payable), conditions or permissions for calling the function. Or any math operations that may result in number overflows.

If that doesn’t help, you can use the debugger tool in remix (https://remix.ethereum.org) and walk through function execution step by step.

Answer 2

It actually tells you a lot of information.

In your Mocha script, find the it which says FPCoin1 One can purchase tokens for ether (the beginning of this string is possibly located at the enclosing describe level).

Inside that it, there is a web3 call which eventually leads to a VM Exception.

Typically, you should strive for a minimal amount of web3 calls inside each it.

If that is indeed the case, then it shouldn't be hard to isolate the one causing the problem.

Otherwise, put each web3 call in a try/catch clause and find the rogue one.

Or even easier, print a unique string after each web3 call, run the test and find the first string which is not printed (the rogue web3 call would be the one that appears right before that string is printed).