process object with weird attributes in Node.js v10.5.0 #209

mmarchini · 2018-06-28T20:38:11Z

0x000002e56df83d09:<Object: process properties {
    .title=<unknown field type>,
    .version=<Smi: 1>,
    .versions=<Smi: 1>,
    .arch=<Smi: 1>,
    .platform=<Smi: 1>,
    .release=<Smi: 1>,
    .argv=0x000002e5ff5aa5e9:<Array: length=2>,
    .execArgv=0x000002e5ff5aa609:<Array: length=2>,
    .env=0x000002e5ff5aa629:<Object: (anonymous)>,
    .pid=<Smi: 1>,
    .features=<Smi: 1>,
    .ppid=<unknown field type>,
    .execPath=0x000002e5ff5aa679:<String: "/Users/mmarchini...">,
    .debugPort=<unknown field type>,
    ._startProfilerIdleNotifier=<unknown field type>,
    ._stopProfilerIdleNotifier=<unknown field type>,
    .abort=<unknown field type>,
    .chdir=0x000002e51d4dbae1:<function: chdir at (external).js:20:33>,
    .umask=0x000002e51d4dbb21:<function: umask at (external).js:24:33>,
    ._getActiveRequests=<unknown field type>,
    ._getActiveHandles=<unknown field type>,
    .reallyExit=<unknown field type>,
    .cwd=<unknown field type>,
    .getuid=<unknown field type>,
    .geteuid=<unknown field type>,
    .getgid=<unknown field type>,
    .getegid=<unknown field type>,
    .getgroups=<unknown field type>,
    ._kill=<unknown field type>,
    .dlopen=<unknown field type>,
    ._debugProcess=<unknown field type>,
    ._debugEnd=<unknown field type>,
    .hrtime=0x000002e51d4dd1a1:<function: hrtime at (external).js:96:35>,
    .cpuUsage=0x000002e51d4dd4f9:<function: cpuUsage at (external).js:35:39>,
    .uptime=<unknown field type>,
    .memoryUsage=0x000002e51d4dd7a9:<function: memoryUsage at (external).js:123:45>,
    ._rawDebug=0x000002e51d4e0fd1:<function: process._rawDebug at (external).js:250:31>,
    .moduleLoadList=<Smi: 1>,
    .binding=<unknown field type>,
    ._linkedBinding=<unknown field type>,
    ._events=0x000002e5ff5aa6c9:<Object: Object>,
    ._eventsCount=<Smi: 4>,
    ._maxListeners=0x000002e532d022e1:<undefined>,
    ._fatalException=<unknown field type>,
    .domain=0x000002e532d02201:<null>,
    ._exiting=0x000002e532d023f1:<false>,
    .assert=<unknown field type>,
    .config=0x000002e5917a4401:<Object: Object>,
    .setUncaughtExceptionCaptureCallback=<unknown field type>,
    .hasUncaughtExceptionCaptureCallback=<unknown field type>,
    .emitWarning=<unknown field type>,
    .nextTick=<unknown field type>,
    ._tickCallback=<unknown field type>,
    .stdout=<unknown field type>,
    .stderr=<unknown field type>,
    .stdin=<unknown field type>,
    .openStdin=<unknown field type>,
    .initgroups=<unknown field type>,
    .setegid=<unknown field type>,
    .seteuid=<unknown field type>,
    .setgid=<unknown field type>,
    .setuid=<unknown field type>,
    .setgroups=<unknown field type>,
    .exit=<unknown field type>,
    .kill=<unknown field type>,
    .argv0=0x000002e5ff5b0a21:<String: "node">,
    .mainModule=0x000002e58cd02ae1:<Object: Module>}>
0x000002e56df89931:<Object: process >

For example, platform=<Smi: 1> should be a string. Node.js v10.4.1 is working fine.

git bisect points to nodejs/node@ba17c9e as the offending commit.

The text was updated successfully, but these errors were encountered:

mmarchini · 2018-07-01T16:55:43Z

@joyeecheung have you found other issues in v10.5.0 besides this one?

joyeecheung · 2018-07-03T09:13:51Z

@mmarchini Not yet, I have not used llnode much with v10.x or master lately

joyeecheung · 2018-07-04T11:34:43Z

Interestingly, llnode is not broken on v10 on Linux: https://travis-ci.com/nodejs/llnode/jobs/132771982/config though it's broken on macOS, I have not tested on other platforms yet.

mmarchini · 2018-07-04T14:10:16Z

Weird, but good to know. I'll try to look into it later this week.

mmarchini · 2018-08-06T16:49:50Z

This issue is reproducible on FreeBSD 11.2-RELEASE with LLDB 4.0 and 6.0.

mmarchini · 2018-08-11T20:17:30Z

There are two issues here: one is the <unknown field type> on the method fields, which is the same from #198. The other one is the <Smi: 1> on the object fields. I'm guessing they were introduced in different commits, so I'll bisect node core again.

I was able to fix the first issue and I'll submit a patch later today.

BTW, the issue was also happening on Linux, but some of our tests are not running there 😕

When the PropertyLocation of the details of a JSObject property is kDescriptor, we can just get the descriptor from the descriptors array and inspect it. This solves several fields being resolved as `<unknown field type>`. Fixes: nodejs#198 Ref: nodejs#209

Some tests (`test/addon/jsapi-test.js` and `test/plugin/scan-test.js`) were not running on Linux because LLDB is not able to save core dumps on that platform. These changes use a simpler approach to save core dumps on Linux so these tests can also be run there. Ref: nodejs#209

joyeecheung · 2018-08-12T20:02:47Z

@mmarchini I believe that's because lldb does not support saving core dumps on Linux (at least not in 3.9)

Read-onlyness shouldn't influnece from where we read the property data. Fixes: nodejs#209

When the PropertyLocation of the details of a JSObject property is kDescriptor, we can just get the descriptor from the descriptors array and inspect it. This solves several fields being resolved as `<unknown field type>`. Fixes: #198 Ref: #209 PR-URL: #221 Refs: #209 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>

When the PropertyLocation of the details of a JSObject property is kDescriptor, we can just get the descriptor from the descriptors array and inspect it. This solves several fields being resolved as `<unknown field type>`. Fixes: nodejs#198 Ref: nodejs#209 PR-URL: nodejs#221 Refs: nodejs#209 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>

Read-onlyness shouldn't influnece from where we read the property data. Fixes: nodejs#209 PR-URL: nodejs#221 Fixes: nodejs#198 Refs: nodejs#209 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>

Some tests (`test/addon/jsapi-test.js` and `test/plugin/scan-test.js`) were not running on Linux because LLDB is not able to save core dumps on that platform. These changes use a simpler approach to save core dumps on Linux so these tests can also be run there. Ref: nodejs#209

When the PropertyLocation of the details of a JSObject property is kDescriptor, we can just get the descriptor from the descriptors array and inspect it. This solves several fields being resolved as `<unknown field type>`. Fixes: nodejs#198 Ref: nodejs#209 PR-URL: nodejs#221 Refs: nodejs#209 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>

Read-onlyness shouldn't influnece from where we read the property data. Fixes: nodejs#209 PR-URL: nodejs#221 Fixes: nodejs#198 Refs: nodejs#209 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>

Some tests (`test/addon/jsapi-test.js` and `test/plugin/scan-test.js`) were not running on Linux because LLDB is not able to save core dumps on that platform. These changes use a simpler approach to save core dumps on Linux so these tests can also be run there. Ref: #209 PR-URL: #222 Refs: #209 Reviewed-By: Joyee Cheung <[email protected]>

Some tests (`test/addon/jsapi-test.js` and `test/plugin/scan-test.js`) were not running on Linux because LLDB is not able to save core dumps on that platform. These changes use a simpler approach to save core dumps on Linux so these tests can also be run there. Ref: nodejs#209 PR-URL: nodejs#222 Refs: nodejs#209 Reviewed-By: Joyee Cheung <[email protected]>

mmarchini added the bug label Jun 28, 2018

joyeecheung mentioned this issue Jul 4, 2018

JS API: initial implementation (N-API version) #206

Closed

This comment has been minimized.

Sign in to view

mmarchini mentioned this issue Aug 8, 2018

src: fix JSError inspection #215

Closed

mmarchini mentioned this issue Aug 11, 2018

src: inspect properties with descriptor details #221

Closed

mmarchini mentioned this issue Aug 12, 2018

test: increase Linux test coverage #222

Closed

mmarchini pushed a commit to mmarchini/llnode that referenced this issue Aug 13, 2018

src: fix inspection of read-only properties

5e3e63b

Read-onlyness shouldn't influnece from where we read the property data. Fixes: nodejs#209

mmarchini closed this as completed in d348eff Aug 20, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

process object with weird attributes in Node.js v10.5.0 #209

process object with weird attributes in Node.js v10.5.0 #209

mmarchini commented Jun 28, 2018

mmarchini commented Jul 1, 2018

Uh oh!

joyeecheung commented Jul 3, 2018

Uh oh!

joyeecheung commented Jul 4, 2018

Uh oh!

mmarchini commented Jul 4, 2018

Uh oh!

mmarchini commented Aug 6, 2018

Uh oh!

This comment has been minimized.

mmarchini commented Aug 11, 2018

Uh oh!

joyeecheung commented Aug 12, 2018

Uh oh!

Uh oh!

process object with weird attributes in Node.js v10.5.0 #209

process object with weird attributes in Node.js v10.5.0 #209

Comments

mmarchini commented Jun 28, 2018

mmarchini commented Jul 1, 2018

Uh oh!

joyeecheung commented Jul 3, 2018

Uh oh!

joyeecheung commented Jul 4, 2018

Uh oh!

mmarchini commented Jul 4, 2018

Uh oh!

mmarchini commented Aug 6, 2018

Uh oh!

This comment has been minimized.

mmarchini commented Aug 11, 2018

Uh oh!

joyeecheung commented Aug 12, 2018

Uh oh!