-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Comments
Can you try it on a modern/supported version of node? v5.x hasn't been supported since 2016. |
i try [email protected] and nothing change npm ERR! A complete log of this run can be found in: |
When i try to delete a directory, and this error is appear. Every thing fine when i don't try to delete directory. |
Try with the latest version in the branch, such as v6.14.2 as of this writing. |
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 |
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:
Specs Window 10 x64 package.json
Error output
|
Could be duplicates of #20297 (somewhere in the inheritance some code sets the underlying pointer to nullptr before the object actually gets garbage collected) |
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... |
cc @addaleax |
@joyeecheung I think your suggestion is okay, it’s at least consistent because that’s what Another (additional?) solution for this problem in other places is to set |
I think the problem comes from here Line 129 in c241b7d
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. |
I tried to write some tests around this case and if we only set |
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]>
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
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
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.
(edited by @vsemozhetbyt: fix backticks for code block)
The text was updated successfully, but these errors were encountered: