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

phamVanLac · 2018-05-15T02:23:07Z

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 · 2018-05-15T02:33:05Z

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

phamVanLac · 2018-05-15T02:42:06Z

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 · 2018-05-15T03:01:09Z

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

mscdex · 2018-05-15T03:02:36Z

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

bricss · 2018-05-25T15:35:48Z

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 · 2018-05-26T04:54:15Z

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 · 2018-05-26T15:11:28Z

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 · 2018-05-26T15:13:38Z

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 · 2018-05-26T15:16:01Z

cc @addaleax

addaleax · 2018-05-26T20:53:07Z

@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 · 2018-05-27T04:31:15Z

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 · 2018-05-27T04:34:51Z

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

Before this commit, when the user calls methods on a closed or errored fs event watcher, they could hit a crash since the FSEventWrap in C++ land may have already been destroyed with the internal pointer set to nullptr. This commit makes sure that the user cannot hit crashes like that, instead the methods calling on a closed watcher will be noops. Also explicitly documents that the watchers should not be used in `close` and `error` event handlers. PR-URL: nodejs#20985 Fixes: nodejs#20738 Fixes: nodejs#20297 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>

Before this commit, when the user calls methods on a closed or errored fs event watcher, they could hit a crash since the FSEventWrap in C++ land may have already been destroyed with the internal pointer set to nullptr. This commit makes sure that the user cannot hit crashes like that, instead the methods calling on a closed watcher will be noops. Also explicitly documents that the watchers should not be used in `close` and `error` event handlers. PR-URL: #20985 Fixes: #20738 Fixes: #20297 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Ron Korving <ron@ronkorving.nl> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com> Backport-PR-URL: #21172

vsemozhetbyt added the fs Issues and PRs related to the fs subsystem / file system. label May 15, 2018

joyeecheung mentioned this issue May 27, 2018

fs: do not crash when using a closed fs event watcher #20985

Closed

4 tasks

richardlau mentioned this issue Jun 2, 2018

node 10.3.0 - fs_event_wrap.cc:91: Assertion `(wrap) != nullptr' failed. #21090

Closed

joyeecheung closed this as completed in cd8f06f Jun 3, 2018

DanielRuf mentioned this issue Jun 8, 2018

[dnm] chore: remove Node.js 4, add Node.js 10 webpack/watchpack#80

Merged

This was referenced Sep 27, 2018

Upgrade to Electron 3 (WIP) beakerbrowser/beaker#1161

Merged

src\fs_event_wrap.cc:90: Assertion `wrap != nullptr' failed (node issue) electron/electron#14844

Closed

OmarTawfik mentioned this issue Feb 7, 2019

Use node 11.9.0 in Appveyor builds sb/smallbasic-editor#11

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

phamVanLac commented May 15, 2018 •

edited by vsemozhetbyt

Loading

mscdex commented May 15, 2018 •

edited

Loading

phamVanLac commented May 15, 2018 •

edited

Loading

phamVanLac commented May 15, 2018

mscdex commented May 15, 2018

bricss commented May 25, 2018 •

edited

Loading

WayneRiesterer commented May 26, 2018

joyeecheung commented May 26, 2018

joyeecheung commented May 26, 2018

joyeecheung commented May 26, 2018

addaleax commented May 26, 2018

joyeecheung commented May 27, 2018

joyeecheung commented May 27, 2018 •

edited

Loading

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

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

Comments

phamVanLac commented May 15, 2018 • edited by vsemozhetbyt Loading

mscdex commented May 15, 2018 • edited Loading

phamVanLac commented May 15, 2018 • edited Loading

phamVanLac commented May 15, 2018

mscdex commented May 15, 2018

bricss commented May 25, 2018 • edited Loading

WayneRiesterer commented May 26, 2018

joyeecheung commented May 26, 2018

joyeecheung commented May 26, 2018

joyeecheung commented May 26, 2018

addaleax commented May 26, 2018

joyeecheung commented May 27, 2018

joyeecheung commented May 27, 2018 • edited Loading

phamVanLac commented May 15, 2018 •

edited by vsemozhetbyt

Loading

mscdex commented May 15, 2018 •

edited

Loading

phamVanLac commented May 15, 2018 •

edited

Loading

bricss commented May 25, 2018 •

edited

Loading

joyeecheung commented May 27, 2018 •

edited

Loading