Native crash in Node 10
roblourens opened this issue · 31 comments
I installed Node 10 on MacOS and Win 10. Used it for various node things with no issues. But starting gulp always results in a native crash. Smells like a Node bug but I report it here because I haven't seen it anywhere else.
Same steps for Mac or Win...
- Have empty gulpfile.js
- Run
gulp - See crash output:
$ gulp
[21:08:45] Using gulpfile ~/code/gulptest/gulpfile.js
gulp[62193]: ../src/node_contextify.cc:631:static void node::contextify::ContextifyScript::New(const FunctionCallbackInfo<v8::Value> &): Assertion `args[1]->IsString()' failed.
1: node::Abort() [/Users/roblou/.nvm/versions/node/v10.0.0/bin/node]
2: node::InternalCallbackScope::~InternalCallbackScope() [/Users/roblou/.nvm/versions/node/v10.0.0/bin/node]
3: node::contextify::ContextifyScript::New(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/roblou/.nvm/versions/node/v10.0.0/bin/node]
4: v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo*) [/Users/roblou/.nvm/versions/node/v10.0.0/bin/node]
5: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<true>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/roblou/.nvm/versions/node/v10.0.0/bin/node]
6: v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/roblou/.nvm/versions/node/v10.0.0/bin/node]
7: 0x2ee39308427d
[1] 62193 abort gulp
Same result if I run ./node_modules/.bin/gulp
What version of gulp are you using?
What versions of npm and node are you using?
$ gulp -v
[21:10:31] CLI version 3.9.1
[21:10:31] Local version 3.9.1
$ node -v
v10.0.0
If you can't reproduce this, I'm happy to debug more, but since I see it in 2 different environments, hopefully it's easy to reproduce.
I tried the following configurations (using Linux):
| Node | Gulp | Gulp-CLI | Empty gulpfile | Result (OK or Error) |
|---|---|---|---|---|
| 9 | 4.0.0 | 2.0.1 | No | OK |
| 10 | 4.0.0 | 2.0.1 | No | OK |
| 10 | 3.9.1 | 2.0.1 | Yes | OK |
| 10 | 3.9.1 | 2.0.1 | Yes | OK |
| 10 | 3.9.1 | 3.9.1 (bundled) | Yes | OK |
I am unable to reproduce your issue (see last line). The only difference is that I am using Linux instead of Mac or Windows.
Here is the project I used, is there a difference with your case?
Could you try to use Gulp 4.0.0 on your system and report if the error still happens? It would at least provide a mitigation for the issue.
The next step would be to locate the line actually causing the error: the Node dump is not very helpful unfortunately.
@demurgos you should probably see nodejs/node#19786 and #2146 as these are related to this issue.
@roblourens Did you run npm update to make sure you get the latest of your tree, and npm rebuild when you upgraded so any native modules already in your dependency tree would be recompiled?
Yes I tried those things. From the other issues, sounds like I'm not the only one seeing this.
@roblourens You're the only one who has reported this issue so far - those other issues linked were historical, and we resolved the issues in those prior to the release.
I'm facing the same issue using Windows 10 and Node 10.
Deleted all node_modules folder after upgrading and ran npm rebuild.
yarn run v1.6.0
(node:15548) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
$ yarn build:css && yarn build:vendor && yarn build:js
(node:11116) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
$ cd css && yarn build
(node:19200) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
$ gulp build
gulp build[14548]: src\node_contextify.cc:631: Assertion `args[1]->IsString()' failed.
1: node::DecodeWrite
2: node::DecodeWrite
3: uv_loop_fork
4: v8::internal::interpreter::BytecodeDecoder::Decode
5: v8::internal::RegExpImpl::Exec
6: v8::internal::RegExpImpl::Exec
7: v8::internal::RegExpImpl::Exec
8: 000001B6AFD04281
I was unable to reproduce on macos with node 10 using @demurgos example.
I was using n not nvm to manage the versions. Can you download a node binary without using a version manager and try to reproduce the results?
I'm having this same issue. You can see the Travis CI Output and the GitHub Repo.
@fishcharlie @roblourens @MichaReiser nothing is going to be done on our side. Maybe you should bring this up with the node folks.
Actually I can't repro with @demurgos' example. I can still repro with other projects, using the same gulp version, so I'm guessing the difference is some other dep in the package-lock.json. But this reproes even after npm update so I don't know what that would be.
@phated It says a fix is in Gulp v4. I see a tag on GitHub for version 4, but it doesn't look to be released on NPM. Any updates on that front?
Also using node from nvm vs normal binary makes no difference
@roblourens there's a patch version of natives that needs to be updated. Check out what their latest version is and compare against your lockfile.
@fishcharlie news to me:
@phated My bad. I was relying on the NPM detail page. I'm assuming that page just displays the latest version.
@fishcharlie yeah, never rely on that page. It's terrible - always use npm info <package>. We are not publishing 4.0.0 as latest until the docs are finished (as we've told node core) which needs time, contributors and money.
I stopped understanding how npm works at some point, I don't know why I wasn't already getting the latest, but yeah forcing natives to 1.1.3 is the right workaround...
Hooray another lockfile failure! So frustrating.
An aside: @roblourens would you be able to DM me on twitter (https://twitter.com/BlaineBublitz) - I'm interested to chat about VS Code + gulp
Just another note that we've started experiencing this on a daily Travis cron, using Gulp 3.9.1, that had been working fine until yesterday - with no changes for months.
Given that Gulp 4 isn't ready for prime time yet, it would be nice to see a fix backported to Gulp 3. I'm not sure exactly what's involved but it's possible it's just a dependency update. But I am assuming the best solution for now is just not to use Node 10!
@tdmalone I think you didn't read the whole thread, which includes the change. It's due to your lock file.
@phated Got it - thank you! I did indeed get confused.
For others coming across this, here's what you need to do for Node 10 support (if using Yarn):
- Find
natives@^1.1.0in your lock file - Change it to
natives@^1.1.3 - Run
yarn
If using npm with a package-lock.json the process will probably be fairly similar.
(Be careful modifying your lock file. There's probably a better way to do it!)
Same issue with the console output.
macOS Sierra 10.12.6
$ node -v
v10.0.0
$ gulp
gulp[3975]: ../src/node_contextify.cc:631:static void node::contextify::ContextifyScript::New(const FunctionCallbackInfo<v8::Value> &): Assertion args[1]->IsString()' failed.
1: node::Abort() [/usr/local/bin/node]
2: node::Assert(char const* const (*) [4]) [/usr/local/bin/node]
3: node::contextify::ContextifyScript::New(v8::FunctionCallbackInfo<v8::Value> const&) [/usr/local/bin/node]
4: v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo*) [/usr/local/bin/node]
5: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<true>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/usr/local/bin/node]
6: v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/bin/node]
7: 0x93d7aa8427d
[1] 3975 abort gulp
Solution is delete node_modules dir and package-lock.json.
Then run sudo npm install --unsafe-perm=true
Thanks the information from @roblourens @MichaReiser @phated @tdmalone .
If you are using yarn you can try the following:
Use yarn why natives to identify the packages using the natives module.
Uninstall these packages with yarn remove and install them again yarn add.
In my case it was the gulp-less-watcher plugin.
@Carlos7646 this solution worked me too, thanks man!
Same error for:
- Windows 10 Enterprise LTSB 64-bit EN
- Node.js 10.0.0
- Grunt 1.0.2
Solution:
rm -rf node_modules
rm -rf package-lock.json
npm cache clean
npm installSee @Carlos7646 and Alberto answers for details.
Thanks.
I wouldn't recommend deleting your entire lock file, unless you're sure that you want to upgrade everything. It's probably better just to upgrade the exact package that is causing the issue (which is natives).
You can also add this to your package.json:
"resolutions": {
"natives": "1.1.3"
},
clearest workaround so far. worked for me (win10, node10)
I was experiencing this issue as well with gulp v3.9.1. Switching to Node v9.0 solved it for me.
@kneeki Node 9 is about to go into maintenance so that'll only help you for so long ;) Try @loopmode's solution above instead.
I was getting the same errors with Node v10 and NPM v6 in one of my projects. Deleting the node_modules directory and the lock file and then re-installing seems to have resolved the issue.
For yarn do yarn upgrade gulp
I think we're all understood here - no need to keep posting the same solutions. Update dependencies when you update node.