Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
phamVanLac opened this issue May 15, 2018 · 12 comments
Closed
Labels
fs Issues and PRs related to the fs subsystem / file system.

Comments

@phamVanLac
Copy link

phamVanLac commented May 15, 2018

  • 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
Copy link
Contributor

mscdex commented May 15, 2018

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

@phamVanLac
Copy link
Author

phamVanLac commented May 15, 2018

i try [email protected] 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! [email protected] start: nodemon node ./bin/www
npm ERR! Exit status 134
npm ERR!
npm ERR! Failed at the [email protected] 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
Copy link
Author

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

@mscdex
Copy link
Contributor

mscdex commented May 15, 2018

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

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

bricss commented May 25, 2018

  • 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! [email protected] start-uat: `grunt && node server.js --uat`
npm ERR! Exit status 134
npm ERR! 
npm ERR! Failed at the [email protected] 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
Copy link

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

cc @addaleax

@addaleax
Copy link
Member

@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
Copy link
Member

I think the problem comes from here

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
Copy link
Member

joyeecheung commented May 27, 2018

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

targos pushed a commit to targos/node that referenced this issue Jun 6, 2018
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 <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Ron Korving <[email protected]>
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
targos pushed a commit that referenced this issue Jun 7, 2018
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 <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Ron Korving <[email protected]>
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>

Backport-PR-URL: #21172
targos pushed a commit that referenced this issue Jun 13, 2018
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 <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: Ron Korving <[email protected]>
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>

Backport-PR-URL: #21172
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fs Issues and PRs related to the fs subsystem / file system.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants