npm[7320]: src\fs_event_wrap.cc:90: Assertion `wrap != nullptr' failed.

[phamVanLac]

• Version: node 5.6.0
• Platform:Windows 64-bit
• Subsystem:

i had used rimraf to remove folder and use fs to remove file after download.
But when delete complete node have issue and i cant find the same on any where.
Thanks you very much.

clearFileAfterDownload (path) {

		if (fs.existsSync(path)) {

			rimraf(path, (err) => {

				if(err) {

					console.log(err);

				}

			});

		}

		if(fs.existsSync(path+'.zip')) {

			fs.unlinkSync(path+'.zip');

		}

}

_{(edited by @vsemozhetbyt: fix backticks for code block)}

[mscdex]

Can you try it on a modern/supported version of node? v5.x hasn't been supported since 2016.

[phamVanLac]

i try npm@6.0.1 and nothing change
npm[5864]: src\fs_event_wrap.cc:90: Assertion wrap != nullptr' failed.
1: node::DecodeWrite
2: node::DecodeWrite
3: node::Start
4: 0000036569886400npm
ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! autofeature@0.0.0 start: nodemon node ./bin/www
npm ERR! Exit status 134
npm ERR!
npm ERR! Failed at the autofeature@0.0.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\LAC\AppData\Roaming\npm-cache_logs\2018-05-15T02_40_56_875Z-debug.log`

[phamVanLac]

When i try to delete a directory, and this error is appear. Every thing fine when i don't try to delete directory.

[mscdex]

Try with the latest version in the branch, such as v6.14.2 as of this writing.

[bricss]

• Version: Node 10.2.1
• Platform: Win10 x64

Happens each time when switching between Git branches, while Grunt is running in watch mode.

grunt[36836]: src\fs_event_wrap.cc:91: Assertion `wrap != nullptr' failed.
 1: node::DecodeWrite
 2: node::DecodeWrite
 3: node::Start
 4: 0000028F67786400
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! ig-myig-fe-main@0.2.932 start-uat: `grunt && node server.js --uat`
npm ERR! Exit status 134
npm ERR! 
npm ERR! Failed at the ig-myig-fe-main@0.2.932 start-uat script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\<Username>\AppData\Roaming\npm-cache\_logs\2018-05-25T14_48_07_433Z-debug.log

[WayneRiesterer]

I'm getting this error too.

I am running the Angular CLI build process with a watcher and then serving up the build via NodeJS:

ng build --output-path dist --watch | nodemon ./server/app.js

Specs

Window 10 x64
NodeJS v10.1.0
Angular CLI 6.0.5

package.json

{
 "name": "wr-mean-seed",
 "version": "0.0.0",
 "license": "MIT",
 "scripts": {
 "serve-dev": "ng build --output-path dist --watch | nodemon ./server/app.js",
 "serve-prod": "ng build --prod | node ./server/app.js",
 "client-start": "ng serve",
 "client-build": "ng build --prod",
 "client-test": "ng test",
 "client-lint": "ng lint",
 "client-e2e": "ng e2e"
 },
 "private": true,
 "dependencies": {
 "@angular/animations": "^6.0.3",
 "@angular/common": "^6.0.3",
 "@angular/compiler": "^6.0.3",
 "@angular/core": "^6.0.3",
 "@angular/forms": "^6.0.3",
 "@angular/http": "^6.0.3",
 "@angular/platform-browser": "^6.0.3",
 "@angular/platform-browser-dynamic": "^6.0.3",
 "@angular/router": "^6.0.3",
 "body-parser": "^1.18.3",
 "core-js": "^2.5.6",
 "express": "^4.16.3",
 "rxjs": "^6.2.0",
 "zone.js": "^0.8.19"
 },
 "devDependencies": {
 "@angular-devkit/build-angular": "^0.6.5",
 "@angular/cli": "~6.0.5",
 "@angular/compiler-cli": "^6.0.3",
 "@angular/language-service": "^6.0.3",
 "@types/jasmine": "~2.8.7",
 "@types/jasminewd2": "~2.0.2",
 "@types/node": "~10.1.2",
 "codelyzer": "^4.3.0",
 "jasmine-core": "~3.1.0",
 "jasmine-spec-reporter": "~4.2.1",
 "karma": "~2.0.2",
 "karma-chrome-launcher": "~2.2.0",
 "karma-coverage-istanbul-reporter": "^2.0.1",
 "karma-jasmine": "~1.1.2",
 "karma-jasmine-html-reporter": "^1.1.0",
 "nodemon": "^1.17.5",
 "protractor": "~5.3.2",
 "ts-node": "~6.0.5",
 "tslint": "~5.10.0",
 "typescript": "2.7.2"
 }
}

Error output

$ ng build --output-path dist --watch | nodemon ./server/app.js
[nodemon] 1.17.5
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node ./server/app.js`
Server listening on localhost:3000
 - yarn serve-dev[2648]: src\fs_event_wrap.cc:90: Assertion `wrap != nullptr' failed.
ENOTEMPTY: directory not empty, rmdir 'C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\dist'
Error: ENOTEMPTY: directory not empty, rmdir 'C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\dist'
 at Object.fs.rmdirSync (fs.js:803:3)
 at MergeMapSubscriber.isDirectory.pipe.operators_1.concatMap.isDir [as project] (C:\Users\wprie\Documents\Wayn
e\node-express-angular-cli-seed\node_modules\@angular-devkit\core\node\host.js:173:20)
 at MergeMapSubscriber._tryNext (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@ang
ular-devkit\core\node_modules\rxjs\internal\operators\mergeMap.js:122:27)
 at MergeMapSubscriber._next (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@angula
r-devkit\core\node_modules\rxjs\internal\operators\mergeMap.js:112:18)
 at MergeMapSubscriber.Subscriber.next (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modul
es\@angular-devkit\core\node_modules\rxjs\internal\Subscriber.js:103:18)
 at MapSubscriber._next (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@angular-dev
kit\core\node_modules\rxjs\internal\operators\map.js:92:26)
 at MapSubscriber.Subscriber.next (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@a
ngular-devkit\core\node_modules\rxjs\internal\Subscriber.js:103:18)
 at Observable.rxjs_1.Observable.obs [as _subscribe] (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-s
eed\node_modules\@angular-devkit\core\node\host.js:212:17)
 at Observable.subscribe (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@angular-de
vkit\core\node_modules\rxjs\internal\Observable.js:162:69)
 at MapOperator.call (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@angular-devkit
\core\node_modules\rxjs\internal\operators\map.js:62:23)
 at Observable.subscribe (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@angular-de
vkit\core\node_modules\rxjs\internal\Observable.js:159:22)
 at MergeMapOperator.call (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@angular-d
evkit\core\node_modules\rxjs\internal\operators\mergeMap.js:87:23)
 at Observable.subscribe (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\@angular-de
vkit\core\node_modules\rxjs\internal\Observable.js:159:22)
 at C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\rxjs\internal\util\subscribeToObs
ervable.js:16:20
 at Object.subscribeToResult (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\rxjs\in
ternal\util\subscribeToResult.js:7:45)
 at MergeMapSubscriber._innerSub (C:\Users\wprie\Documents\Wayne\node-express-angular-cli-seed\node_modules\rxj
s\internal\operators\mergeMap.js:132:38)
 1: node::DecodeWrite
 2: node::DecodeWrite
 3: node::Start
 4: 000002D4E3806400
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

[joyeecheung]

Could be duplicates of #20297 (somewhere in the inheritance some code sets the underlying pointer to nullptr before the object actually gets garbage collected)

[joyeecheung]

A quick-and-dirty fix would be to turn the binding into a noop if the underlying pointer is set to nullptr instead of checking it, but that probably just hides the real bug...

[joyeecheung]

cc @addaleax

[addaleax]

@joyeecheung I think your suggestion is okay, it’s at least consistent because that’s what ASSIGN_OR_RETURN_UNWRAP does.

Another (additional?) solution for this problem in other places is to set ._handle to null once the handle closes so that it can’t be accessed anymore – that might be trickier, but probably worth it because it’s also more consistent with most other code we have and would make us detect bugs like this earlier (whatever exactly this bug is).

[joyeecheung]

I think the problem comes from here

node/src/handle_wrap.cc

Line 129 in c241b7d

delete wrap;

Technically the watcher should not be used anymore once it's closed, I am guessing it's not followed by the user land hence the crashes.

[joyeecheung]

Another (additional?) solution for this problem in other places is to set ._handle to null once the handle closes so that it can’t be accessed anymore – that might be trickier, but probably worth it because it’s also more consistent with most other code we have and would make us detect bugs like this earlier (whatever exactly this bug is).

I tried to write some tests around this case and if we only set ._handle to null without any other change, it's going to hit the assertion the next time a method is called on the closed watcher. Seeing the user land usage here I am leaning towards returning early if ._handle is null as well (even though it's not supposed to happen if the docs are followed).