Repository navigation
[Regression in 14.1.0 - Windows] stdout is sometimes empty #33166
Description
- Version: 14.1.0
- Platform: Windows 64-bit on VirtualBox and on Travis CI
- Subsystem: N/A
Bug description
After the Node.js 14.1.0 release, Babel's CI tests on Windows started failing. The failures are all related to @babel/cli and @babel/node: we run those CLI programs, capture their output (from stdout) and compare it with the expected output.
Sometimes, the generated stdout is empty: you can see an example here or here. In this CI log you can also see some error messages coming from V8 internals in @babel/node tests, but I don't know if it's the same problem.
How often does it reproduce? Is there a required condition?
My guess is that every test has about 1% chance of failing. However, we have ~100 tests for those 2 packages so something is failing more often than not.
What steps will reproduce the bug?
I couldn't find a small and isolated reproduction example. I'll keep trying to create one, but here is what I have for now.
Also, building Babel on Windows is painful and I couldn't run the full test suite. However, I managed to reproduce the bug.
I'm running these commands using Powershell, Nodej.s 14.1.0 and Yarn 1.22
# Clone the babel repository
git clone https://github.com/babel/babel.git .
# Install deps
yarn
yarn lerna bootstrap # This takes a while
# Build Babel (this won't build everything, but enough packages to show the bug)
yarn gulp build-no-bundle
# Run the @babel/cli and @babel/node tests
yarn jest --runInBand babel-node babel-cliIf you don't see the last command failing, try running it 2 or three times. The --runInBand option isn't necessary to reproduce the problem, but it disables Jest's workers so it removes one possible cause.
What is the expected behavior?
Tests should pass
What do you see instead?
An example of output failing locally is this:
PS C:\Users\Nicolò\Downloads\babel-master\babel-master> yarn jest --runInBand babel-node babel-cli
yarn run v1.22.4
$ C:\Users\Nicolò\Downloads\babel-master\babel-master\node_modules\.bin\jest --runInBand babel-node babel-cli
FAIL packages/babel-cli/test/index.js (33.099s)
● bin/babel › --only glob
"C:\Users\Nicolò\Downloads\babel-master\babel-master\packages\babel-cli\lib\babel" "--presets" "C:\Users\Nicolò\Downloads\babel-master\babel-master\packages\babel-preset-react" "--plugins" "C:\Users\Nicolò\Downloads\babel-master\babel-master\packages\babel-plugin-transform-arrow-functions,C:\Users\Nicolò\Downloads\babel-master\babel-master\packages\babel-plugin-transform-strict-mode,C:\Users\Nicolò\Downloads\babel-master\babel-master\packages\babel-plugin-transform-modules-commonjs" "src" "--out-dir" "lib" "--only" "**/*.foo.js" "--verbose": expect(received).toBe(expected) // Object.is equality
Expected: "src/a.foo.js -> lib/a.foo.js
src/baz/b.foo.js -> lib/baz/b.foo.js
Successfully compiled 2 files with Babel."
Received: ""
85 | expect(stdout).toContain(expectStdout);
86 | } else {
> 87 | expect(stdout).toBe(expectStdout);
| ^
88 | }
89 | } else if (stdout) {
90 | throw new Error("stdout:\n" + stdout);
at assertTest (packages/babel-cli/test/index.js:87:22)
at ChildProcess.<anonymous> (packages/babel-cli/test/index.js:152:9)
PASS packages/babel-node/test/index.js (22.924s)
Test Suites: 1 failed, 1 passed, 2 total
Tests: 1 failed, 89 passed, 90 total
Snapshots: 0 total
Time: 56.088s, estimated 62s
Ran all test suites matching /babel-node|babel-cli/i.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.Additional information
-
You can see here how we capture
stdoutfor@babel/clitests, . For@babel/nodeit's the same. -
@JLHwung suggested that this might be related to stream: don't wait for close on legacy streams #33058 or stream: don't emit end after close #33076
-
The bug is not present when using Node.js 14.0
Activity
lpinca commentedon Apr 30, 2020
cc: @nodejs/streams @ronag
mcollina commentedon Apr 30, 2020
Can you confirm this happening only on Windows? This is widely unexpected.
ronag commentedon Apr 30, 2020
I can't reproduce on OSX. @nicolo-ribaudo any chance you could bisect? I don't have a Windows machine at the moment.
ronag commentedon Apr 30, 2020
I'm unsure where to go with the V8 errors. @addaleax maybe?
nicolo-ribaudo commentedon Apr 30, 2020
Yes, I can only reproduce this on windows (not the V8 errors), only the empty
stdouts. I'll try to bisect.addaleax commentedon Apr 30, 2020
@ronag I’m not sure… Stack traces on Windows are basically garbage unless you take some extra steps (that I don’t know how to take), and given that the error message isn’t particularly helpful here either – there are over 2000 instances of
UNREACHABLE();in V8 – I’m not quite sure where to start here./cc @nodejs/v8 @nodejs/platform-windows
nicolo-ribaudo commentedon Apr 30, 2020
Update: this might not be a Node.js bug.
Today I made two local clones of the Babel repository: one ~6 hours ago and I can consistently reproduce the errors there, and one ~2 hours ago where I cannot reproduce the errors. This makes me think that maybe it's a bug in a dependency that didn't support Node.js 14.1.0 on windows, and it was recently updated to fix the bug.
Even if there was a bug in a dependency I don't think that it should trigger the V8 internal error, but I cannot reproduce that one anyway 🤷
I'll try to re-run the build on Travis CI a bunch of times, and see if I can reproduce it there.
ronag commentedon Apr 30, 2020
Can you diff the dependencies?
nicolo-ribaudo commentedon Apr 30, 2020
Yeah I'm trying. I'm on a Windows VM and I haven't used Windows for a while, so it might take some time 😛
Also, another thing I noticed: in the folder where I can (consistently!) reproduce the problem, I can only reproduce it when using Node.js 14.1.0. If I use a build form
master(4b2d958) it doesn't fail.ronag commentedon Apr 30, 2020
Yea, a bisect would be very useful.
nicolo-ribaudo commentedon Apr 30, 2020
I gave up for today, I will continue tomorrow.
Also, I noticed that Jest's own tests have the same problem: https://github.com/facebook/jest/pull/9934/checks?check_run_id=633574558 (cc @SimenB)
dr-js commentedon May 1, 2020
Not sure if it's related, I got
win10 + nodejs@14 + babelon CI with flakyELIFECYCLE/3221225477exit code in one of my repo: nodejs/help#2660Update:
I've reduced CI exit test case to some of my source files and babel + 2 babel plugins
The code is at: https://github.com/dr-js/dr-dev/tree/8e111ec5194adc3e159db2d3bc3594f8587dc230
The latest CI fail: https://github.com/dr-js/dr-dev/actions/runs/92784081
Update 2:
With more debug log found the exit happen before the
@babel/envplugin gets load, afterminify-replaceandmodule-resolverloaded.Related CI run: https://github.com/dr-js/dr-dev/actions/runs/92845322
SimenB commentedon May 1, 2020
Yeah, Jest is failing often on Node 14.1.0 on Windows with empty stdout in one test or the other almost every test run. The V8 thing is actually in the latest build on master: https://github.com/facebook/jest/runs/634830924
nicolo-ribaudo commentedon May 1, 2020
Ok, have no idea where to start bisecting. I can still consistently reproduce the failures with the Node.js 14.1.0 installed with the installer, but not if I build 9ffd8e7.
142 remaining items
SimenB commentedon Jun 24, 2020
This still happens using node 14.4.0, fwiw. See https://github.com/facebook/jest/pull/10188/checks?check_run_id=802977045
mcollina commentedon Jun 29, 2020
Maybe @orangemocha can help here.
orangemocha commentedon Jun 29, 2020
Looping in @bzoz @joaocgreis @jaimecbernardo
bzoz commentedon Jun 29, 2020
Sorry, I cannot reproduce with 14.4.0.
@dr-js/dev@0.3.0
@dr-js/dev@0.3.0
@dr-js/dev@0.4.0-dev.1
vm: add importModuleDynamically option to compileFunction
targos commentedon Nov 20, 2021
It seems like this is fixed now. Please reopen if I'm mistaken.
Revert "vm: add importModuleDynamically option to compileFunction"