webpack@4, node@13, Mac crashes when compiler.watch().close() #10037

AviVahl · 2019-11-26T14:48:53Z

Bug report

When closing a watching compiler programmatically, the node process crashes.

What is the current behavior?
Getting the following crash in several repositories on our Mac CIs:

Assertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c, line 187.
error Command failed with signal "SIGABRT".

If the current behavior is a bug, please provide the steps to reproduce.

clone repo: https://github.com/AviVahl/lodash-es-webpack4
yarn
paste the following to a.js:

const webpack = require('webpack');
const compiler = webpack({ mode: 'development' });

function createWatcher() {
    const watcher = compiler.watch({}, () => {
        console.log('watching');
        setTimeout(() => {
            watcher.close(() => {
                console.log('closed watcher');
                createWatcher();
            });
        }, 1000);
    });
}

createWatcher();

node a.js

What is the expected behavior?
(for the above code) watch -> wait for 1 sec -> close watcher -> rewatch and repeat process.

Other relevant information:
webpack version: 4.41.2
Node.js version: 13.2.0
Operating System: Mac 10.12.6

@sokra maybe this is because watchpack is using old chokidar with outdated fsevents? :/

The text was updated successfully, but these errors were encountered:

MarcGaumont · 2019-12-28T05:47:17Z

Have the exact same problem...

AviVahl · 2019-12-28T09:09:21Z

To be honest, I wanted to re-check whether this is still an issue with fsevents@1.2.11 (which added Node 12 compatibility)... I use a Linux machine, so I need to get my hands on a Mac.

AviVahl · 2019-12-29T13:37:02Z

I've re-checked the above instructions... still crashes on Mac and Node 13.

alexander-akait · 2019-12-30T11:19:38Z

What is version node? 13.0, 13.1, other? Looks like bug on node side

PandaWhisperer · 2020-01-19T09:38:02Z

Checking in from the Nuxt.js issue that was just linked. Node.js 13.5.0 with macOS 10.15.2 here.

KrimoPixelsmith · 2020-01-19T21:51:21Z

Same issue here node 13.2, npm 6.13.4, macOS 10.15.2

alexander-akait · 2020-01-20T10:47:16Z

Can you try to update node to latest version?

AviVahl · 2020-01-20T11:01:28Z

just re-tested on Node 13.6.0 with latest webpack. re-produced the issue consistently.

Btw, I'm not certain it's a Node issue. Mac is the only platform where watchpack doesn't use native node APIs and instead uses fsevents (via chokidar). The issue could be there...

KrimoPixelsmith · 2020-01-20T15:08:24Z

@evilebottnawi just like @AviVahl said, it's the exact same; from what I could tell looking online, it looks like it's a chokidar/fsevents issue; I first noticed it in using https://github.com/JeffreyWay/laravel-mix, which uses chokidar version 2.0.x and webpack 4 still;

Looks like v3 is out...

PandaWhisperer · 2020-01-21T14:01:23Z

Can confirm. Updated to node 13.6.0 and the error still occurs.

mahnunchik · 2020-02-01T13:06:13Z

The same error. Node v13.6.0

vjpr · 2020-02-07T10:03:56Z

I am testing with v13.8 now.

7iomka · 2020-02-08T15:57:49Z

Assertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c, line 187.
Abort trap: 6
$ node -v
v13.6.0

:(

DevJonTaylor · 2020-02-09T15:17:58Z

node v13.8.0
macOS 10.15.2 (19C57)
When hot-loading an update it does not crash with this error.
I tested with scss-node | html | and javascript using *.js, *.vue, and *.scss files.

However when closing the node I receive the error again.

 DONE  Compiled successfully in 1153ms                                                                                                      9:15:29 AM


  App running at:
  - Local:   http://localhost:8080/ 
  - Network: http://192.168.1.11:8080/

^CAssertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c, line 187.
zsh: abort      npm run serve
jontaylor@Jonathans-MacBook-Pro portfolio %

sokra · 2020-02-10T05:40:11Z

For webpack 4 we can't upgrade to chokidar 3, as this would be a breaking change. This would need to be fixed in a chokidar for webpack 4 to benefit from it. I also see these errors randomly occuring in the CI build.

For webpack 5 we migrated away from chokidar and native dependencies. I no longer see these errors in the webpack CI builds.

kelly-tock · 2020-02-10T15:52:04Z

i'm getting this as well on node 13.8 with karma and karma webpack. was fine on node v11.12

Nikodermus · 2020-03-05T16:40:14Z

Failing as well

node v13.8.0
macos mojave 10.14 (18A391)

gansdot · 2020-03-15T15:56:55Z

Am also getting the below error. npm server crashes after few mins connecting to mongo db. any idea why this is ?

Assertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c, line 187.
zsh: abort npm run dev

alexander-akait · 2020-04-08T17:41:29Z

Anyone experiencing a problem please read - fsevents/fsevents#314

Briefly - not fixable, not sure if even I send a fix for it, it will be merged.

Good news - webpack@5 doesn't use fsevents, so no problems

AviVahl · 2020-04-09T06:03:40Z

That's a shame, because this started failing with the newly released Node 12.16.2 as well. :(

alexander-akait · 2020-04-09T11:23:43Z

@AviVahl You can open a new issue, maybe when the number of issues becomes more, they will change their minds

aminebenkeroum · 2020-04-12T13:55:16Z

Same experience : Node v13.8.0, Mac Catalina OS

slgarkea · 2020-04-20T07:26:00Z

Edit: nope, this not work. This is weird, some build finishes successfully randomly.

I fixed it by forcing chokidar in his last version :

  "resolutions": {
    "chokidar": "3.3.1"
  }

No anormal behaviour seen so far.

edi · 2020-04-28T06:59:55Z

Same here (using Expo bare-minimum).
Node v13.6.0
Mac Catalina OS

allaniftrue · 2020-05-02T23:17:35Z

I'm using node v12.16.3 (npm v6.14.4) and i still get the same error

Assertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c

AviVahl · 2020-05-07T21:50:26Z

Issue got replaced with another:

> fsevents@1.2.13 install /Users/runner/runners/2.169.1/work/mocha-pup/mocha-pup/node_modules/watchpack/node_modules/fsevents
> node install.js

internal/modules/cjs/loader.js:638
    throw err;
    ^

Error: Cannot find module 'nan'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at [eval]:1:1
    at Script.runInThisContext (vm.js:122:20)
    at Object.runInThisContext (vm.js:329:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at evalScript (internal/bootstrap/node.js:590:27)
gyp: Call to 'node -e "require('nan')"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error 
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/Users/runner/hostedtoolcache/node/10.20.1/x64/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Darwin 19.4.0
gyp ERR! command "/Users/runner/hostedtoolcache/node/10.20.1/x64/bin/node" "/Users/runner/hostedtoolcache/node/10.20.1/x64/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/runner/runners/2.169.1/work/mocha-pup/mocha-pup/node_modules/watchpack/node_modules/fsevents
gyp ERR! node -v v10.20.1
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok

Happens for mocha-pup for all node 10/12/14 on Mac.

The new issue appears to already be documented here: fsevents/fsevents#325

Now's the twist. when I tried to reproduce in a separate project using Node v12.16.3 (npm v6.14.4), I've encountered what seems to be a bug in how npm handles optional dependencies.

If I:

mkdir testing
cd testing
npm init -y
npm i webpack

And then look in the package-lock.json file, I can see that fsevents has been resolved to v1.2.13, and that it requires nan:

    "fsevents": {
      "version": "1.2.13",
      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-1.2.13.tgz",
      "integrity": "sha512-oWb1Z6mkHIskLzEJ/XWX0srkpkTQ7vaopMQkyaEIoq0fmtFVxOthb8cCxeT+p3ynTdkk/RZwbgG4brR5BeWECw==",
      "optional": true,
      "requires": {
        "bindings": "^1.5.0",
        "nan": "^2.12.1"
      }

nan is also found is the lock file.

But if I run the same set of commands, just adding chokidar to the install command:

mkdir testing
cd testing
npm init -y
npm i webpack chokidar

Then the package-lock.json contains:

        "fsevents": {
          "version": "1.2.13",
          "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-1.2.13.tgz",
          "integrity": "sha512-oWb1Z6mkHIskLzEJ/XWX0srkpkTQ7vaopMQkyaEIoq0fmtFVxOthb8cCxeT+p3ynTdkk/RZwbgG4brR5BeWECw==",
          "optional": true
        },

Without the "requires", and without nan appearing anywhere in the lock file.

It seems the existence of another fsevents version in the tree affects how the dependencies of fsevents@1 are resolved by npm, leading to the missing nan install errors.

The above behavior reproduces consistently (try it yourself) and leads me to believe that depending on which dependencies are in your project, you might experience one of two behaviors:

Error during postinstall of fsevents just on Mac (on all node versions), which doesn't fail npm install, being an optionalDependency. There would be no runtime crashes, as fsevents isn't used.
No errors during postinstall anywhere, but runtime crash when programmatically closing the watch compiler on Node@14/Mac and maybe on latest Node@12 as well.

This also accounts for why some people no longer see the crash, and others do (in comments above).

paulmillr · 2020-05-08T22:47:46Z

You should ask maintainers to upgrade to fsevents v2.

AviVahl · 2020-05-08T23:50:33Z

@paulmillr already answered is in this thread: #10037 (comment)

webpack@4 needs to support node@6, which newer chokidar/fsevents does not. I can't really argue with that need. I'm just stuck until webpack releases v5 and the loader/plugin ecosystem adapts to the new version.

Well, TBH, not really stuck... we've added workarounds in several of our code-bases to force no watching when in "single-run" mode... :/ This can get a bit hairy, because sometimes it's abstractions like webpack-dev-middleware which call the watcher. We ended up monkey patching the webpack's compiler so every call to .watch() will call .run() instead:
https://github.com/wixplosives/engine/blob/v13.0.2/packages/scripts/src/application.ts#L186
https://github.com/wixplosives/mocha-pup/blob/v3.0.0/src/run-tests.ts#L43

These are just two examples from open source projects.

I hate these workarounds, but we are already using Node 12 in production and started supporting 14. We cannot be held back by such issues.

paulmillr · 2020-05-09T02:55:07Z

@AviVahl not really. There is an effort to upgrade to chokidar 3, maintainers merged pull request/s already. Ask them to release new versions asap.

AviVahl · 2020-05-16T17:59:46Z

Alright, so the latest releases of watchpack@1 should fix the crash. How, might you ask? It's installing two versions of chokidar with a try/catch to each (newer version gets higher priority). I'll save what I really think about this approach, and just say the "postinstall" errors we get from chokidar@2 are far from ideal. :(

sokra · 2020-05-16T18:26:38Z

@AviVahl I also dislike that. Technically chokidar2 should only be installed when node<8, but npm seem to ignore that. Works fine in yarn.
We will get rid of that in the next major version, but for semver reasons we need to support node 6 in watchpack 1 and webpack 4. (I know that it is out of lifetime, but that doesn't allow us to break semver here)

paulmillr · 2020-05-16T18:41:46Z

@sokra see this comment on "removing chokidar in next major version". The file watching task is not as simple as it looks.

AviVahl · 2020-05-17T00:37:37Z

@sokra both npm@6.14.4 (comes with latest node 12/14) and yarn@1.22.4 (current "latest" for yarn) warn about and install duplicate chokidar and fsevents versions. I initialized an empty project and just npm i watchpack / yarn add watchpack. So the statement about any of them being ignored may be incorrect.

Alternative possible solution:
Re-release latest webpack@4 as 5, breaking just min Node version. Re-direct current 5 to 6. Supporting it in loaders/plugins would be easy, as there would be no other breaking changes. This is probably the "proper" solution, and will allow webpack to both keep Node 6 support and have clean Node 12/14 support.

All this juggling of dependency versions is starting to get out of hand. You end up using older versions of packages just to keep supporting an unsupported Node version.

Meanwhile, consumer projects using LTS versions of Node end up having duplicate dependencies, weird post-install errors, and failing CI builds due to runtime errors (original issue).

I mean, we've been dealing with this for quite a while now. Consumer projects started having the original issue over 6 months ago.

Having said the above, I wanna add that I appreciate your hard work, and will respect whatever decision you end up taking here.

briandipalma · 2020-05-17T06:44:40Z

We're not going to run out of numbers any time soon, releasing Webpack 5 just to drop node 6 support seems reasonable.

AviVahl · 2020-05-18T18:42:46Z

Alright, I am closing this issue, as the reported crash should now be fixed (make sure your project has watchpack resolved to v1.7.2 or above).

There's a separate new issue (postinstallation errors) which is expected to resolve itself with webpack@5.

Motivation ---------- fixes mswjs#188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on MacOS with some regularity. That is because it depends on chokidar 2 which uses the `fsevents` api which has a [crictical bug][2] on MacOS. Approach -------- This manually forces all modules to use chokidar 3 which does not use the `fsevents` module at all. While this does trigger a semver violation because webpack 4 depends on chokidar 2, the API is apparently similar enough that all the tests pass. It does however give rise to a warning in the console upon installation of depedencies via a `yarn`. This resolution can be removed once an upgrade is made to webpack 5 or to a different depedency bundler like [parcel][3] or [rollup][4]. Learning -------- * [Selective dependency resolutions ][5] [1]: webpack/webpack#10037 [2]: fsevents/fsevents#314 [3]: http://parceljs.org [4]: https://rollupjs.org [5]: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

Motivation ---------- fixes #188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on MacOS with some regularity. That is because it depends on chokidar 2 which uses the `fsevents` api which has a [crictical bug][2] on MacOS. Approach -------- This manually forces all modules to use chokidar 3 which does not use the `fsevents` module at all. While this does trigger a semver violation because webpack 4 depends on chokidar 2, the API is apparently similar enough that all the tests pass. It does however give rise to a warning in the console upon installation of depedencies via a `yarn`. This resolution can be removed once an upgrade is made to webpack 5 or to a different depedency bundler like [parcel][3] or [rollup][4]. Learning -------- * [Selective dependency resolutions ][5] [1]: webpack/webpack#10037 [2]: fsevents/fsevents#314 [3]: http://parceljs.org [4]: https://rollupjs.org [5]: https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

The fix turns out to be bumping `webpack` from `4.43` to `4.44` in `packages/web-components`. Prior to this, I'd experience sporadic errors when running `yarn test` like the ones documented in this `karma` issue: [karma-runner/karma#3511](karma-runner/karma#3511). It turns out, that the problem is not with `karma` but rather with `webpack` as documented in [webpack/webpack#10037](webpack/webpack#10037). As per the closing comment in that issue, ensure we use `watchpack` version `^1.7.2` (a transitive dep of `webpack`) is enough to ensure this sporadic error goes away, and to bump `watchpack` we need to bump `webpack` by one minor version.

- There are two issues. One is: webpack/webpack#10037. - Likely related alongside this, is the socket and frontend not connecting with one another. Was able to drill down to figure out the frontend is the issue. fsevents dependency and two versions on Mac seems to be messing things up - Above seemed to point to needing to update to webpack 5 in order to use this on Macs. - Updated most dependencies. Not socket.io-client (4.5.3), nanoid (4.0.0), winston (3.8.2) yet. - React updated to 18.2 from 17. react-scripts from 4 to 5 - react-app-rewired installed for config-overrides to try to fix new bugs coming up. Installed os-browserify, browserify-zlib for this. - I think I pointlessly installed react-router. Seems like that wasn’t around before. Downgraded from react-router and react-router-dom 6 to 5. Initially react-router-dom was at 5.3. Likely go back to that next commit and remove react-router.

talebi1 mentioned this issue Jan 18, 2020

Error every time I modify and save nuxt.config.js nuxt/nuxt#6848

Closed

KrimoPixelsmith mentioned this issue Jan 19, 2020

BrowserSync fails with watch task: Assertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c, line 187 laravel-mix/laravel-mix#2313

Closed

bensmithett mentioned this issue Feb 15, 2020

Webpack 4 watcher crashes under Node 13 bensmithett/tropical#4

Closed

This was referenced Apr 7, 2020

segmentation fault on node 13.12 and macOS Catalina 10.15 (v1.2.12) fsevents/fsevents#314

Closed

chore: migrate to github-actions webpack/webpack-dev-middleware#611

Merged

eidng8 mentioned this issue Apr 22, 2020

add more browsers to e2e test eidng8/vue-tree#23

Open

4 tasks

QuintinWillison mentioned this issue May 12, 2020

segmentation fault running local browser tests ably/delta-codec-js#7

Open

devoto13 mentioned this issue May 15, 2020

Assertion failed : (0) at the end of karma execution karma-runner/karma#3511

Closed

AviVahl closed this as completed May 18, 2020

marcosvega91 mentioned this issue Jun 19, 2020

Integration tests fail locally with "function uv_close" mswjs/msw#188

Closed

yury-s mentioned this issue Jul 23, 2020

[BUG] GitHub + macOS + Node 14: All tests pass but process exits with code 134 microsoft/playwright#3090

Closed

cowboyd mentioned this issue Jul 27, 2020

🐛Force usage of chokidar 3 mswjs/msw#298

Merged

hxykjc mentioned this issue Aug 4, 2020

Update chokidar to new major version (version 3) webpack/webpack-dev-server#2683

Closed

2 tasks

haoqunjiang mentioned this issue Aug 5, 2020

Assertion Failed error on server stop vuejs/vue-cli#5748

Closed

thoughtspile mentioned this issue Dec 11, 2020

WIP: TEST: Добавить тесты VKCOM/VKUI#1152

Merged

kubkon mentioned this issue Jan 18, 2021

fix(libuv): fix sporadic libuv assertion fails microsoft/fluentui#16513

Closed

jeffwhitfield mentioned this issue Feb 8, 2021

uikit-workshop 5.5.0 crashes during serve when adding an empty pattern file pattern-lab/patternlab-node#1114

Closed

tzimmermann mentioned this issue Apr 29, 2022

chore: make tests green again signavio/react-stick#385

Merged

webpack@4, node@13, Mac crashes when compiler.watch().close() #10037

webpack@4, node@13, Mac crashes when compiler.watch().close() #10037

Comments

AviVahl commented Nov 26, 2019

Bug report

MarcGaumont commented Dec 28, 2019

AviVahl commented Dec 28, 2019

AviVahl commented Dec 29, 2019

alexander-akait commented Dec 30, 2019 • edited Loading

PandaWhisperer commented Jan 19, 2020

KrimoPixelsmith commented Jan 19, 2020

alexander-akait commented Jan 20, 2020

AviVahl commented Jan 20, 2020

KrimoPixelsmith commented Jan 20, 2020 • edited Loading

PandaWhisperer commented Jan 21, 2020

mahnunchik commented Feb 1, 2020

vjpr commented Feb 7, 2020

7iomka commented Feb 8, 2020

DevJonTaylor commented Feb 9, 2020

sokra commented Feb 10, 2020

kelly-tock commented Feb 10, 2020

Nikodermus commented Mar 5, 2020

gansdot commented Mar 15, 2020

alexander-akait commented Apr 8, 2020

AviVahl commented Apr 9, 2020

alexander-akait commented Apr 9, 2020

aminebenkeroum commented Apr 12, 2020

slgarkea commented Apr 20, 2020 • edited Loading

edi commented Apr 28, 2020

allaniftrue commented May 2, 2020

AviVahl commented May 7, 2020

paulmillr commented May 8, 2020

AviVahl commented May 8, 2020

paulmillr commented May 9, 2020

AviVahl commented May 16, 2020

sokra commented May 16, 2020

paulmillr commented May 16, 2020

AviVahl commented May 17, 2020

briandipalma commented May 17, 2020

AviVahl commented May 18, 2020

alexander-akait commented Dec 30, 2019 •

edited

Loading

KrimoPixelsmith commented Jan 20, 2020 •

edited

Loading

slgarkea commented Apr 20, 2020 •

edited

Loading