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

Getting ._handle through --inspect with chrome developer tools crashes Node.js #16949

Closed
sboys3 opened this issue Nov 11, 2017 · 6 comments
Closed
Labels
c++ Issues and PRs that require attention from people who are familiar with C++.

Comments

@sboys3
Copy link

sboys3 commented Nov 11, 2017

  • Version: 8.9.1
  • Platform: 64 bit windows

If you try to get the value of ._handle through chrome devtools using the --inspect flag Node.js will crash with the error:
C:\Program Files\nodejs\node.exe: c:\ws\src\util-inl.h:243: Assertion (object->InternalFieldCount()) > (0)' failed.
For example entering process.stdin._handle or http.createServer().listen()._handle will crash Node.js. If you try to inspect process.stdin or someting else with a .handle and you expand it in devtool it will crash Node.js as well.

image

@TimothyGu
Copy link
Member

TimothyGu commented Nov 11, 2017

Probably the same issue as node-canvas was facing in #15099. We just need to do more of #16860 (in fact #16860 might have already fixed this, will need to confirm).

Edit: Indeed, #16860 fixes this. On current master the following is shown:

screenshot from 2017-11-11 01-31-34

@TimothyGu TimothyGu added the c++ Issues and PRs that require attention from people who are familiar with C++. label Nov 11, 2017
@addaleax addaleax added the v8.x label Nov 11, 2017
@roderickObrist
Copy link

Version: 8.9.1
Platform: Ubuntu 17.10 x86
Command: node --inspect=9222 index.js

/usr/bin/node[32436]: ../src/util-inl.h:243:TypeName* node::Unwrap(v8::Local<v8::Object>) [with TypeName = node::LibuvStreamWrap]: Assertion `(object->InternalFieldCount()) > (0)' failed.
 1: node::Abort() [/usr/bin/node]
 2: node::Assert(char const* const (*) [4]) [/usr/bin/node]
 3: void node::StreamBase::GetBytesRead<node::LibuvStreamWrap>(v8::Local<v8::String>, v8::PropertyCallbackInfo<v8::Value> const&) [/usr/bin/node]
 4: v8::internal::PropertyCallbackArguments::Call(void (*)(v8::Local<v8::Name>, v8::PropertyCallbackInfo<v8::Value> const&), v8::internal::Handle<v8::internal::Name>) [/usr/bin/node]
 5: v8::internal::Object::GetPropertyWithAccessor(v8::internal::LookupIterator*) [/usr/bin/node]
 6: v8::internal::Object::GetProperty(v8::internal::LookupIterator*) [/usr/bin/node]
 7: v8::internal::JSReceiver::GetOwnPropertyDescriptor(v8::internal::LookupIterator*, v8::internal::PropertyDescriptor*) [/usr/bin/node]
 8: v8::internal::JSReceiver::GetOwnPropertyDescriptor(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyDescriptor*) [/usr/bin/node]
 9: v8::internal::Builtin_ObjectGetOwnPropertyDescriptor(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/bin/node]
10: 0x14f46748441d

I'm not sure if the "me too" is appreciated but I thought I might as well add my stack trace of seemingly the same problem

@TimothyGu
Copy link
Member

@roderickObrist Upgrading to 8.9.2 (when it is released) should fix this.

@jure
Copy link
Contributor

jure commented Dec 8, 2017

Why did this start asserting anyway? Can we go back to the way things were?

In 8.8.1 process.stdin._handle.__proto__.bytesRead simply returns undefined:

8.8.1:
image

In 8.9.2, it throws.

8.9.2:
image

This is an issue when, for example, using node-config to configure bunyan; somewhere in the chain node-config clones by accessing properties in the proto https://github.com/lorenwest/node-config/blob/master/lib/config.js#L1216, this now throws. Catching the error thrown here means that parent !== child and circular structures aren't caught (and that blows the call stack).

To summarise, why can't it just be undefined again?

Edited by @TimothyGu to fix formatting.

@TimothyGu
Copy link
Member

Has this been fixed in #17665?

@TimothyGu
Copy link
Member

Actually the OP was fixed in 8.9.2, and #16949 (comment) in #17665. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++.
Projects
None yet
Development

No branches or pull requests

5 participants