Ts-node-dev: Infinite loop, 100% CPU

Created on 4 Jun 2019  路  17Comments  路  Source: wclr/ts-node-dev

In ts-node-dev-hooks, the compile function runs this:

waitForFile(compiledPath + '.done')

which ends up in the function waitForFile. This runs an infinite loop as the file is never created. This is the block:

var waitForFile = function(fileName) {
  var start = new Date().getTime()
  while (true) {
    const exists = execCheck
      ? execSync(['node', checkFileScript, '"' + fileName + '"'].join(' '), {
          stdio: 'inherit'
        }) || true
      : fs.existsSync(fileName)

    if (exists) {
      return
    }
    var passed = new Date().getTime() - start
    if (timeThreshold && passed > timeThreshold) {
      throw new Error('Could not require ' + fileName)
    }
  }
}

exists is always false, execCheck is false. timeThreshold is 0

Unless I misunderstand the code, it also seems terribly "spinny". Why don't we use file watchers, or something like 100ms polling? We should also bail out after a timeout - e.g. no produced file within say 10 seconds or so. Why is timeThreshold 0?

Most helpful comment

@wclr I did some digging on this and the issue seems to be related to fork. I built a minimal repro: https://gist.github.com/LucasPickering/f1568762a2a774923f15a8f6b5781c87

If you clone that repo and do npm install, you should see these results:

npm run start

This runs with just ts-node, and the output is:

> [email protected] start /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro
> ts-node index.ts

Starting process: /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/process.ts
Starting child process...

and it quickly exits, which is what we'd expect. With ts-node-dev though...

npm run start-dev

output looks like:

> [email protected] start-dev /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro
> ts-node-dev --debug index.ts

Ignore watch: []
[INFO] 16:31:23 ts-node-dev ver. 1.1.1 (using ts-node ver. 9.1.1, typescript ver. 4.1.2)
[DEBUG] 16:31:23 Starting child process -r /var/folders/vg/tmnjzzr93pb3t8xq53v7fd5c0000gn/T/ts-node-dev-hook-6849730767871609.js /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/node_modules/ts-node-dev/lib/wrap.js index.ts
[DEBUG] 16:31:23 /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/index.ts added to watcher
[DEBUG] 16:31:24 /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/index.ts compiled in 811 ms
Starting process: /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/process.ts
[DEBUG] 16:31:24 /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/process.ts added to watcher

and then it just hangs. I tried downgrading TypeScript to 4.1.2 (and 4.0.0 for good measure) and still saw the issue, so I'm not sure how long this has been around. Would you mind taking another look at this? Please let me know if there's any other info I can give that would be helpful.

All 17 comments

Unless I misunderstand the code, it also seems terribly "spinny"

because it is a hack to make compilation in parent process to be synchronous.

Make a repo to reproduce if it is possible.

unfortunately i can't - will definitely get back if it occurs again. Still though - wouldn't it be reasonable to have a 10-20 seconds threshold? Seems the code's there, just that timeThreshold should have another value

Well, this is actually the abnormal situation if it can not find the compiled source, need to understand what causes it, threshold timeout won't help to fix the process.

So I got this again...when doing "git work", merging, having conflicts, switching branches. Have no more details than that though. Any clues because of that?

run with --debug option and see on what file it stucks.

I ran into this as well. For me it seemed to be related to node 10.16.0. Downgrading to 10.15.x resolved it.

@tmont thanks, it's work for me. I Downgrading to 10.13.0 LTS, resolved.

I am experiencing the same issue.
macOS 10.14.6
node 10.16.3
ts-node-dev 1.0.0-pre.30

Same issue with "ts-node-dev": "^1.0.0-pre.42" and Node 10.16.0

Will close for now.

Just seeing this on [email protected]. Downgrading to [email protected] has no issues. Regular ts-node works without issue on both versions.

Using node v14.7.0.

@whitecolor Can we re-open?

Downgrading to [email protected] has no issues

This is really strange.

Actually repro example is needed. At least --debug output.

@wclr I did some digging on this and the issue seems to be related to fork. I built a minimal repro: https://gist.github.com/LucasPickering/f1568762a2a774923f15a8f6b5781c87

If you clone that repo and do npm install, you should see these results:

npm run start

This runs with just ts-node, and the output is:

> [email protected] start /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro
> ts-node index.ts

Starting process: /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/process.ts
Starting child process...

and it quickly exits, which is what we'd expect. With ts-node-dev though...

npm run start-dev

output looks like:

> [email protected] start-dev /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro
> ts-node-dev --debug index.ts

Ignore watch: []
[INFO] 16:31:23 ts-node-dev ver. 1.1.1 (using ts-node ver. 9.1.1, typescript ver. 4.1.2)
[DEBUG] 16:31:23 Starting child process -r /var/folders/vg/tmnjzzr93pb3t8xq53v7fd5c0000gn/T/ts-node-dev-hook-6849730767871609.js /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/node_modules/ts-node-dev/lib/wrap.js index.ts
[DEBUG] 16:31:23 /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/index.ts added to watcher
[DEBUG] 16:31:24 /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/index.ts compiled in 811 ms
Starting process: /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/process.ts
[DEBUG] 16:31:24 /Users/lucas.pickering/MarkForged/ts-node-dev-74-repro/process.ts added to watcher

and then it just hangs. I tried downgrading TypeScript to 4.1.2 (and 4.0.0 for good measure) and still saw the issue, so I'm not sure how long this has been around. Would you mind taking another look at this? Please let me know if there's any other info I can give that would be helpful.

@LucasPickering make github repo to clone, not gist, please.

@wclr Were you able to look into this/make any progress?

Was this page helpful?
0 / 5 - 0 ratings