Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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.

# for free to join this conversation on GitHub. Already have an account? # 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