Unresponsive with 100% CPU

I was trying out solidity-coverage today but running into issues testing it out. I have ~17 contracts, and after “Instrumenting…” the process pegs one CPU core at 100% and never seems to finish(waited a bit over 1 hour).

How can I go about debugging this? I’ve tried the traditional node DEBUG env var with no useful output.

DEBUG="*" ./node_modules/.bin/solidity-coverage

Here’s my .solcover.js file. I have tried without specifying port, testCommand, and norpc as well(also, ganache appears to not receive any transactions during this process).

module.exports = {
    port: 8545,
    testCommand: './node_modules/.bin/truffle test --network dev',
    norpc: true,
    copyNodeModules: true,
    skipFiles: ['Test.sol']
};

The process can not be terminated through a keyboard interrupt(ctrl+c) either. I’m running this on an Arch Linux system, if that helps. Let me know if I can provide any more information.

[h3ph4est7s]

Hi @vs77bb the project type is Traditional so its 1 worker at a time i cannot participate if there is a way that i don’t currently know please inform me 😄. Also i wanted to clarify that i already have the diagnosis due to a project im working on and using oraclize service with solidity-coverage and i wasn’t targeting on the bounty in the first place (it came out as a bonus) also i want to apologize to @mttmartin for the highjack.

[h3ph4est7s]

The exclusion issue arrise when the line https://github.com/sc-forks/solidity-coverage/blob/a40ba7b1b4c4fe03352eb4899aa27931a6734f6b/lib/app.js#L390 in postProcessPure does not properly check for excluded files. #259 is addressing this issue by adding an exclusion file/folder check. As for the bug itself the process “hangs” (in the matter of fact is working) because of the unbracketed singleton statement parser at https://github.com/sc-forks/solidity-coverage/blob/a40ba7b1b4c4fe03352eb4899aa27931a6734f6b/lib/preprocessor.js#L40 is too slow when it comes to parsing large contracts the main issue is the loop using: https://github.com/sc-forks/solidity-coverage/blob/a40ba7b1b4c4fe03352eb4899aa27931a6734f6b/lib/preprocessor.js#L45 witch takes a lot of time to parse all the contract in every pass. The aforementioned claim can be verified by applying the following patch:

--- lib/preprocessor.js (revision a40ba7b1b4c4fe03352eb4899aa27931a6734f6b)
+++ lib/preprocessor.js (date 1531305439000)
@@ -42,7 +42,10 @@
 
   while (keepRunning) {
     try {
+      console.time('parse');
       const ast = SolidityParser.parse(contract);
+      console.log('length: ' + contract.length);
+      console.timeEnd('parse');
       keepRunning = false;
       SolExplore.traverse(ast, {
         enter(node, parent) { // eslint-disable-line no-loop-func
@@ -84,6 +87,7 @@
         },
       });
     } catch (err) {
+      console.log(err);
       contract = err;
       keepRunning = false;
     }

and getting this output:

length: 46508
parse: 41473.762ms
length: 46500
parse: 41236.352ms
length: 46502
parse: 43498.465ms
length: 46504
parse: 41831.958ms
length: 46506
parse: 40028.604ms

and after approx. 40 * 40 / 60 = 26,66 minutes later

length: 46544
parse: 38760.110ms
length: 46540
parse: 41115.355ms
length: 46542
parse: 38606.990ms
length: 46544
parse: 36695.497ms
length: 46546
parse: 47062.380ms

this indicates that every iteration take approximately 40 seconds (in my machine), multiply that with the number of required passes and the result is really time consuming.

The conditions are triggered when using usingOraclize.sol (SHA256: 79283d8e5f4f30fe33c6b0ab2296531bdd159f19438ec18fe9ebae2a5bc7edae) file at: https://github.com/sc-forks/solidity-coverage/blob/a40ba7b1b4c4fe03352eb4899aa27931a6734f6b/lib/app.js#L393