[Bug]: Random segfaults when running webpack and using @babel/core 7.16.10

[Artur-]

💻

• Would you like to work on a fix?

How are you using Babel?

Other (Next.js, Gatsby, vue-cli, ...)

Input code

No idea how to reproduce it. It reproduces in random places in our CI builds, starting from yesterday after the release of 7.16.10

Configuration file name

No response

Configuration

No response

Current and expected behavior

Apparently we are using Babel through workbox which is used through webpack which is run from Java

├─┬ workbox-build@6.4.1
│ ├─┬ @babel/core@7.16.10

The only expectation I have is that webpack should finish the build instead of segfault. Assuming here that exit value 139 means segmentation fault.

Environment

• Babel: 7.16.10
• Node 16.0.0

Possible solution

Downgrading to @babel/core 7.16.7 resolves the problem

Additional context

https://github.com/vaadin/flow/runs/4882425225?check_suite_focus=true is an example of a failed build but it does not provide much more information

https://github.com/vaadin/flow/runs/4882529524 is the same build but with babel 7.16.7

[babel-bot]

Hey @Artur-! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite.

[jlowcs]

I might be experiencing a similar issue in our circleci builds. I'm not seeing a segfault, but the build sometimes fails right away without any information from webpack.

This is a node build (webpack target is node) and it fails about 10% of the time. Our browser build seems to work fine though.

[jlowcs]

We also noticed that a random segfault appeared in our eslint CI job since bumping babel. eslint uses @babel/eslint-parser.

[Artur-]

I was unable to get a core dump out from our CI yet. Maybe posting or analyzing that will give more clues

[jlowcs]

For reference, here are our version changes from our babel bump that introduced the issues:

@babel/core: 7.16.7 => 7.16.10
@babel/helper-create-class-features-plugin: 7.16.7 => 7.16.10
@babel/parser: 7.16.8 => 7.16.10
@babel/plugin-proposal-private-methods: 7.16.7 => 7.16.11
@babel/plugin-transform-runtime: 7.16.8 => 7.16.10
@babel/preset-env: 7.16.8 => 7.16.11
@babel/traverse: 7.16.8 => 7.16.10

[nicolo-ribaudo]

Could any of you try using patch-package or Yarn 2/3's patch: protocol, or a script that you run on CI after installing your dependencies but before running webpack, to comment out line 23 from https://unpkg.com/browse/@babel/core@7.16.10/lib/config/files/import-meta-resolve.js?

That line might cause nodejs/node#35889 if for some reason webpack is running inside a Node.js vm context, and without more details (or better, if someone manages to reproduce the error outside of CI and can share the repository that I can use to debug the problem) it's the only clue I have.

[jlowcs]

I just created a branch with that patch. Now, since the segfault doesn't happen every time, I'm gonna have to run the CI multiple times to confirm the issue has actually disappeared.

[jlowcs]

so far, my eslint job has run without failing 5 times out of 5 with that patch.

[jlowcs]

10/10 on the eslint job, and 5/5 on the node build, so it looks like that patch does fix the issue.

[Artur-]

I will see if I can monkey patch this and test also. Seems like patch-package does not support pnpm so I cannot use that

[Artur-]

After a couple of failing patch attempts I think I now agree with @jlowcs that removing

try {
 import_ = require("./import").default;
} catch (_unused) {}

resolves the issue

[nicolo-ribaudo]

@Artur- thanks! If you have time, could you also test if what I wrote in the description of #14192 (review) works too (rather than deleting that try/catch)?

[Artur-]

With this change vaadin/flow@94f26a0 all I see is [webpack-cli] ReferenceError: polyfill is not defined. Should polyfill be something else like _importMetaResolve.resolve?

[nicolo-ribaudo]

Oh yes right, it should be _importMetaResolve.resolve 😅

[Artur-]

That fix seems to also resolve the issue

[nicolo-ribaudo]

I'm releasing 7.16.12 with the workaround for this V8 bug.

[jlowcs]

thank you!