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

[mmarchini]

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.

[mmarchini]

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

[joyeecheung]

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

[joyeecheung]

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]

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

[mmarchini]

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

[mmarchini]

Interesting. I thought this could be an issue with clang builds, but building node on Linux with clang gives the correct output. Running llnode on OSX to inspect a Linux binary + core dump also gives the correct output. I wonder what's so different between Linux and OSX/FreeBSD to cause such a weird bug.

[mmarchini]

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 😕

[joyeecheung]

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