Truffle: `truffle test` fails with 'out of gas' on all solidity tests

[nbauernfeind]

• [x] I've asked for help in the Truffle Gitter before filing this issue.

---

Issue

Truffle v4.1.7 fails to run simple solidity test contract. Note that v4.1.6 works fine.

Steps to Reproduce

npm -g install [email protected]
Try to run test:

pragma solidity ^0.4.21;

import "truffle/Assert.sol";

contract Test {
  function testRun() {
  }
}

Expected Behavior

  Test
    ✓ testRun (51ms)


  1 passing (1s)

Actual Results

  Test
    1) "before all" hook: prepare suite


  0 passing (989ms)
  1 failing

  1) Test "before all" hook: prepare suite:
     Error: VM Exception while processing transaction: out of gas
      at Object.InvalidResponse (/usr/local/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/errors.js:38:1)
      at /usr/local/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/requestmanager.js:86:1
      at /usr/local/lib/node_modules/truffle/build/webpack:/~/truffle-provider/wrapper.js:134:1
      at XMLHttpRequest.request.onreadystatechange (/usr/local/lib/node_modules/truffle/build/webpack:/~/web3/lib/web3/httpprovider.js:128:1)
      at XMLHttpRequestEventTarget.dispatchEvent (/usr/local/lib/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:64:1)
      at XMLHttpRequest._setReadyState (/usr/local/lib/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:354:1)
      at XMLHttpRequest._onHttpResponseEnd (/usr/local/lib/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:509:1)
      at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/truffle/build/webpack:/~/xhr2/lib/xhr2.js:469:1)
      at endReadableNT (_stream_readable.js:1101:12)
      at process._tickCallback (internal/process/next_tick.js:114:19)

Environment

• Operating System: osx
• Ethereum client: n/a
• Truffle version (truffle version): 4.1.7
• node version (node --version): 9.9.0
• npm version (npm --version): 5.8.0

[cgewecke]

@nbauernfeind Was not able to reproduce this unfortunately. We run MetaCoin's solidity tests as part of our CI and those are passing as well. In your issue you've left the client info out - could you clarify how you're launching the tests?

I'm also on OSX, in an empty project, running a fresh install of 4.1.7. Added your test and ran:

truffle test

Output

Can you identify a difference here?

[nbauernfeind]

@cgewecke Thanks for your quick reply. You're right, on a fresh init it works fine. The problem seems to introduce itself when I override the gas property in truffle.js. I'm running through Ganache and the limit I have here is definitely under the configured gas limit in Ganache.

This is my truffle.js:

module.exports = {
  networks: {
    development: {
      host: "127.0.0.1",
      port: 7545,
      network_id: "*",
      gasPrice: 1,
      gas: 6000000,
    }
  }
};

[nbauernfeind]

Ahh.. actually I see what's going on. Turns out that simple test contract is getting more and more expensive. Does truffle test use a different default gas limit than truffle migrate? I had tuned it up to handle the migration and must have been lucky. It seems on v4.1.6 it cost 5913212 gas and now on v4.1.7 it costs 6109322 to deploy the test contract.

[cgewecke]

@nbauernfeind Ah yes that makes sense, good to know. It was modified to clear warnings produced by solc 0.4.22. Could be that the new solc compiles things a little more expensively as well. . .

[storebot]

Ahh.. actually I see what's going on. Turns out that simple test contract is getting more and more expensive. Does truffle test use a different default gas limit than truffle migrate? I had tuned it up to handle the migration and must have been lucky. It seems on v4.1.6 it cost 5913212 gas and now on v4.1.7 it costs 6109322 to deploy the test contract.

@nbauernfeind I tested on Truffle v4.1.15 (core: 4.1.15) the exact values are between 6109258 - 6721975, anything less or more of this range does not work. Would you be able to explain why?

[nbauernfeind]

I no longer work at that company and don't have an environment setup to further investigate. If I recall correctly, I used a value higher than 6.7M -- but at first I was trying to keep it high enough but not super close to the block limit. Things greatly improved when I turned on compiler optimizations... Sorry I'm not super interested anymore and can't quite help you further.