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

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? 😕

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 32
Comments: 41 (8 by maintainers)

Commits related to this issue

🐛Force usage of chokidar 3 Motivation ---------- fixes https://github.com/mswjs/msw/issues/188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on Ma... — committed to cowboyd/msw by cowboyd 4 years ago
🐛Force usage of chokidar 3 Motivation ---------- fixes https://github.com/mswjs/msw/issues/188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on Ma... — committed to cowboyd/msw by cowboyd 4 years ago
🐛Force usage of chokidar 3 Motivation ---------- fixes https://github.com/mswjs/msw/issues/188 The current version of webpack that we're using has [a bug][1] that causes the tests to crashes on Ma... — committed to mswjs/msw by cowboyd 4 years ago
fix(libuv): fix sporadic `libuv` assertion fails 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 runni... — committed to kubkon/fluentui by deleted user 3 years ago
fix(libuv): fix sporadic `libuv` assertion fails 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 runni... — committed to kubkon/fluentui by deleted user 3 years ago
fix(libuv): fix sporadic `libuv` assertion fails 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 runni... — committed to kubkon/fluentui by deleted user 3 years ago
Major bug issue — not resolved - There are two issues. One is: https://github.com/webpack/webpack/issues/10037. - Likely related alongside this, is the socket and frontend not connecting with one ano... — committed to ssaadh/zoomers-collab-timers by ssaadh 2 years ago

Most upvoted comments

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

allaniftrue on May 2, 2020

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 %

DevJonTaylor on Feb 9, 2020

@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.

AviVahl on May 17, 2020

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…

AviVahl on Jan 20, 2020

@evilebottnawi same error as before, Assertion failed: (0), function uv_close, file ../deps/uv/src/unix/core.c, line 187.

KrimoPixelsmith on Apr 29, 2020

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.

slgarkea on Apr 28, 2020

Anyone experiencing a problem please read - https://github.com/fsevents/fsevents/issues/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

alexander-akait on Apr 8, 2020

I am testing with v13.8 now.

vjpr on Feb 7, 2020

The same error. Node v13.6.0

mahnunchik on Feb 1, 2020