profile
viewpoint
Matheus Marchini mmarchini @Netflix Bay Area https://mmarchini.me/ BPF and stuff; @nodejs collaborator; OSS enthusiast and coffee lover;

jdewit/bootstrap-timepicker 1678

[Deprecated] A simple timepicker component for Twitter Bootstrap

brendangregg/bpf-perf-tools-book 407

Official repository for the BPF Performance Tools book

mmarchini/docker-node-builder 1

✨Docker images to build Node.js ✨

mmarchini/admin 0

Facilitating joint collaboration amongst the TSC and CommComm

mmarchini/awesome-nodejs 0

:zap: Delightful Node.js packages and resources

mmarchini/awesome-python 0

A curated list of awesome Python frameworks, libraries and software

issue commentnodejs/node-v8

`./configure --debug` not working without `--experimental-enable-pointer-compression`

Upstream bug: https://bugs.chromium.org/p/v8/issues/detail?id=10257

mmarchini

comment created time in a day

issue commentnodejs/node-v8

`./configure --debug` not working without `--experimental-enable-pointer-compression`

FWIW:

# on V8 8.2.141
$ gn gen --args='is_debug=true v8_enable_pointer_compression=false v8_enable_31bit_smis_on_64bit_arch=false' out/x64.debug.test
Done. Made 143 targets from 86 files in 80ms

$ ninja -C out/x64.debug.test d8
ninja: Entering directory `out/x64.debug.test'
[1410/1418] ACTION //:run_mksnapshot_default(//build/toolchain/linux:clang_x64)
FAILED: gen/embedded.S snapshot_blob.bin 
python ../../tools/run.py ./mksnapshot --turbo_instruction_scheduling --target_os=linux --target_arch=x64 --embedded_src gen/embedded.S --embedded_variant Default --random-seed 314159265 --startup_blob snapshot_blob.bin --native-code-counters --verify-heap


#
# Fatal error in ../../src/codegen/x64/assembler-x64.h, line 123
# Debug check failed: SmiValuesAre31Bits().
#
#
#
#FailureMessage Object: 0x7fffad2da500
==== C stack trace ===============================

    /home/mmarchini/workspace/chromium/v8/v8/out/x64.debug.test/libv8_libbase.so(v8::base::debug::StackTrace::StackTrace()+0x13) [0x7f76dc880cd3]
    /home/mmarchini/workspace/chromium/v8/v8/out/x64.debug.test/libv8_libplatform.so(+0x112ad) [0x7f76dc84e2ad]
    /home/mmarchini/workspace/chromium/v8/v8/out/x64.debug.test/libv8_libbase.so(V8_Fatal(char const*, int, char const*, ...)+0x153) [0x7f76dc8764c3]
    /home/mmarchini/workspace/chromium/v8/v8/out/x64.debug.test/libv8_libbase.so(+0x1ad55) [0x7f76dc875d55]
    ./mksnapshot(+0x17704e7) [0x55966a77f4e7]
    ./mksnapshot(+0x169959c) [0x55966a6a859c]
    ./mksnapshot(v8::internal::SetupIsolateDelegate::SetupBuiltinsInternal(v8::internal::Isolate*)+0x9bd) [0x55966a66d48d]
    ./mksnapshot(v8::internal::SetupIsolateDelegate::SetupBuiltins(v8::internal::Isolate*)+0x17) [0x55966a1702f7]
    ./mksnapshot(v8::internal::Isolate::Init(v8::internal::ReadOnlyDeserializer*, v8::internal::StartupDeserializer*)+0xe9b) [0x5596698642cb]
    ./mksnapshot(v8::internal::Isolate::InitWithoutSnapshot()+0xd) [0x55966986341d]
    ./mksnapshot(v8::SnapshotCreator::SnapshotCreator(v8::Isolate*, long const*, v8::StartupData*)+0xc9) [0x5596695b9c79]
    ./mksnapshot(v8::internal::CreateSnapshotDataBlobInternal(v8::SnapshotCreator::FunctionCodeHandling, char const*, v8::Isolate*)+0x43) [0x559669f51e33]
    ./mksnapshot(+0x59bfc0) [0x5596695aafc0]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f76dbd711e3]
    ./mksnapshot(_start+0x2a) [0x5596695a5e3a]
ninja: build stopped: subcommand failed.


mmarchini

comment created time in a day

issue commentnodejs/node-v8

Failing test: test-inspector-multisession-ws

My current theory is that we're hitting pause right after a script is loaded, parsed, maybe even compiled, and pushed onto the stack, but it's not quite ready to run yet.

Why this is happening so frequently? When session.on runs, it will require files in the inspector thread. When console.log runs, it will require several files if they were not required yet. Since the script is so small and only requires inspect, most Node.js modules are not loaded by defautl (on most common cases, those modules will be loaded when a pause happens, thus the crash doesn't happen). This test is, unfortunately (or fortunately), well crafted enough to trigger this crash quite frequently, because it has several requires happening indirectly "during execution" (not as consequence of direct requires).

Why this is not happening on master? No idea

Is this a bug on V8, Node.js or in our test? I'm inclined to say V8, but want to look a bit further before opening a bug anywhere.

There are a few fixes we can apply to the test if we want to unblock the upgrade and investigate this issue in parallel. Let me know if that's something you want, I can send a patch.


<details> <summary>Notes I took while debugging, mostrly unstrucutred, unfiltered, and unrevised</summary>

If I add a small delay between Debugger.resume and Debugger.pause, the test will pass. That doesn't seem like the right way to fix though, but suggests we have something like a race condition here (especially since the test passes sometimes). This could also explain why Chrome DevTools doesn't crash the script.

Starting the process with --inspect and Debugger.resume -> Debugger.pause on repeat doesn't seem to cause the issue, so it seems like something exclusive to how --inspect-brk is implemented.


The debug build is hitting a DCHECK on the same function the Release build is crashing (here). We're likely reaching that code while in an inconsistent state.

Here's the (supposedly) stack trace on the DCHECK when it fails (printed using gdbinit's jst):

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x55a4e9a62fff]
Security context: 0x3a3408280545 <JSObject>#0#
    1: /* anonymous */(aka /* anonymous */) [0x3a340817e0c9] [internal/worker/io.js:1] [bytecode=0x3a340833c395 offset=-1](this=0x3a340804030d <undefined>,0x3a34080cce49 <Object map = 0x3a34082402d9>#1#,0x3a34080c301d <JSFunction nativeModuleRequire (sfi = 0x3a3408296629)>#2#,0x3a34080cce09 <NativeModule map = 0x3a3408244041>#3#,0x3a34080c213d <process map = 0x3a340825a7a1>#4#,0x3a34080c3ae1 <JSFunction internalBinding (sfi = 0x3a3408296709)>#5#,0x3a3408287121 <Object map = 0x3a34082412f1>#6#)
    2: compileForInternalLoader [0x3a34080c6151] [internal/bootstrap/loaders.js:276] [bytecode=0x3a3408299ea1 offset=112](this=0x3a34080cce09 <NativeModule map = 0x3a3408244041>#3#)
    3: nativeModuleRequire(aka nativeModuleRequire) [0x3a34080c301d] [internal/bootstrap/loaders.js:305] [bytecode=0x3a3408299d29 offset=79](this=0x3a340804030d <undefined>,0x3a3408339a15 <String[#18]: internal/worker/io>)
    4: /* anonymous */(aka /* anonymous */) [0x3a340817db0d] [internal/worker.js:34] [bytecode=0x3a340833a411 offset=376](this=0x3a340804030d <undefined>,0x3a34080ccdc5 <Object map = 0x3a34082402d9>#7#,0x3a34080c301d <JSFunction nativeModuleRequire (sfi = 0x3a3408296629)>#2#,0x3a34080ccd85 <NativeModule map = 0x3a3408244041>#8#,0x3a34080c213d <process map = 0x3a340825a7a1>#4#,0x3a34080c3ae1 <JSFunction internalBinding (sfi = 0x3a3408296709)>#5#,0x3a3408287121 <Object map = 0x3a34082412f1>#6#)
    5: compileForInternalLoader [0x3a34080c6151] [internal/bootstrap/loaders.js:276] [bytecode=0x3a3408299ea1 offset=112](this=0x3a34080ccd85 <NativeModule map = 0x3a3408244041>#8#)
    6: nativeModuleRequire(aka nativeModuleRequire) [0x3a34080c301d] [internal/bootstrap/loaders.js:305] [bytecode=0x3a3408299d29 offset=79](this=0x3a340804030d <undefined>,0x3a3408339985 <String[#15]: internal/worker>)
    7: /* anonymous */(aka /* anonymous */) [0x3a340816188d] [worker_threads.js:9] [bytecode=0x3a3408339899 offset=4](this=0x3a340804030d <undefined>,0x3a34080cda3d <Object map = 0x3a34082402d9>#9#,0x3a34080c301d <JSFunction nativeModuleRequire (sfi = 0x3a3408296629)>#2#,0x3a34080cd9fd <NativeModule map = 0x3a3408244041>#10#,0x3a34080c213d <process map = 0x3a340825a7a1>#4#,0x3a34080c3ae1 <JSFunction internalBinding (sfi = 0x3a3408296709)>#5#,0x3a3408287121 <Object map = 0x3a34082412f1>#6#)
    8: compileForInternalLoader [0x3a34080c6151] [internal/bootstrap/loaders.js:276] [bytecode=0x3a3408299ea1 offset=112](this=0x3a34080cd9fd <NativeModule map = 0x3a3408244041>#10#)
    9: nativeModuleRequire(aka nativeModuleRequire) [0x3a34080c301d] [internal/bootstrap/loaders.js:305] [bytecode=0x3a3408299d29 offset=79](this=0x3a340804030d <undefined>,0x3a340831dff1 <String[#14]: worker_threads>)
   10: /* anonymous */(aka /* anonymous */) [0x3a34081615a9] [inspector.js:29] [bytecode=0x3a3408338855 offset=253](this=0x3a340804030d <undefined>,0x3a34080c7a3d <Object map = 0x3a34082402d9>#11#,0x3a34080c301d <JSFunction nativeModuleRequire (sfi = 0x3a3408296629)>#2#,0x3a34080c79f9 <NativeModule map = 0x3a3408244041>#12#,0x3a34080c213d <process map = 0x3a340825a7a1>#4#,0x3a34080c3ae1 <JSFunction internalBinding (sfi = 0x3a3408296709)>#5#,0x3a3408287121 <Object map = 0x3a34082412f1>#6#)
   11: compileForInternalLoader [0x3a34080c6151] [internal/bootstrap/loaders.js:276] [bytecode=0x3a3408299ea1 offset=112](this=0x3a34080c79f9 <NativeModule map = 0x3a3408244041>#12#)
   12: compileForPublicLoader [0x3a34080c60fd] [internal/bootstrap/loaders.js:218] [bytecode=0x3a34083386f9 offset=49](this=0x3a34080c79f9 <NativeModule map = 0x3a3408244041>#12#)
   13: loadNativeModule(aka loadNativeModule) [0x3a340813e9ed] [internal/modules/cjs/helpers.js:24] [bytecode=0x3a3408332051 offset=48](this=0x3a340804030d <undefined>,0x3a3408295fa9 <String[#9]: inspector>,0x3a3408295fa9 <String[#9]: inspector>)
   14: _load [0x3a3408323c45] [internal/modules/cjs/loader.js:919] [bytecode=0x3a3408330ebd offset=224](this=0x3a340813599d <JSFunction Module (sfi = 0x3a340830950d)>#13#,0x3a3408295fa9 <String[#9]: inspector>,0x3a340814fcc9 <Module map = 0x3a340825e8f1>#14#,0x3a340804044d <false>)
   15: require [0x3a3408323cb1] [internal/modules/cjs/loader.js:1093] [bytecode=0x3a3408338535 offset=85](this=0x3a340814fcc9 <Module map = 0x3a340825e8f1>#14#,0x3a3408295fa9 <String[#9]: inspector>)
   16: require(aka require) [0x3a3408150ba5] [internal/modules/cjs/helpers.js:72] [bytecode=0x3a3408338441 offset=10](this=0x3a340804030d <undefined>,0x3a3408295fa9 <String[#9]: inspector>)
   17: /* anonymous */ [0x3a3408150919] [/tmp/aa/fooo.js:1] [bytecode=0x3a340833819d offset=15](this=0x3a340814fdc1 <Object map = 0x3a34082402d9>#15#,0x3a340814fdc1 <Object map = 0x3a34082402d9>#15#,0x3a3408150ba5 <JSFunction require (sfi = 0x3a3408337f71)>#16#,0x3a340814fcc9 <Module map = 0x3a340825e8f1>#14#,0x3a340814f5cd <String[15]: /tmp/aa/fooo.js>,0x3a3408150b39 <String[7]: /tmp/aa>)
   18: InternalFrame [pc: 0x55a4e984081a]
   19: EntryFrame [pc: 0x55a4e98405f8]
   20: builtin exit frame: callAndPauseOnStart(this=0x3a34080c0121 <JSGlobal Object>#17#,0x3a3408150b39 <String[7]: /tmp/aa>,0x3a340814f5cd <String[15]: /tmp/aa/fooo.js>,0x3a340814fcc9 <Module map = 0x3a340825e8f1>#14#,0x3a3408150ba5 <JSFunction require (sfi = 0x3a3408337f71)>#16#,0x3a340814fdc1 <Object map = 0x3a34082402d9>#15#,0x3a340814fdc1 <Object map = 0x3a34082402d9>#15#,0x3a3408150919 <JSFunction (sfi = 0x3a340833652d)>#18#,0x3a34080c0121 <JSGlobal Object>#17#)

   21: _compile [0x3a3408323cdd] [internal/modules/cjs/loader.js:1201] [bytecode=0x3a340833581d offset=417](this=0x3a340814fcc9 <Module map = 0x3a340825e8f1>#14#,0x3a3408150739 <String[315]\: const { Session } = require('inspector');\nconst session = new Session();\nlet done = false;\n\nfunction lala() {\n  // process._rawDebug('hey oh');\n  setInterval(lala, 150);\n}\nlala();\nsession.on('Debugger.paused', () => {\n  // done = true;\n});\nsession.connect();\nsession.post('Debugger.enable');\nconsole.log('Ready');\n\n>,0x3a340814f5cd <String[15]: /tmp/aa/fooo.js>)
   22: .js [0x3a3408323d09] [internal/modules/cjs/loader.js:1224] [bytecode=0x3a3408333095 offset=155](this=0x3a3408147f91 <Object map = 0x3a3408242629>#19#,0x3a340814fcc9 <Module map = 0x3a340825e8f1>#14#,0x3a340814f5cd <String[15]: /tmp/aa/fooo.js>)
   23: load [0x3a3408323c85] [internal/modules/cjs/loader.js:1053] [bytecode=0x3a3408332679 offset=189](this=0x3a340814fcc9 <Module map = 0x3a340825e8f1>#14#,0x3a340814f5cd <String[15]: /tmp/aa/fooo.js>)
   24: _load [0x3a3408323c45] [internal/modules/cjs/loader.js:948] [bytecode=0x3a3408330ebd offset=403](this=0x3a340813599d <JSFunction Module (sfi = 0x3a340830950d)>#13#,0x3a3408134d3d <String[15]: /tmp/aa/fooo.js>,0x3a3408040171 <null>,0x3a34080403e5 <true>)
   25: runMain(aka executeUserEntryPoint) [0x3a340814ebd5] [internal/modules/run_main.js:71] [bytecode=0x3a340832e075 offset=86](this=0x3a340813599d <JSFunction Module (sfi = 0x3a340830950d)>#13#,0x3a3408134d3d <String[15]: /tmp/aa/fooo.js>)
   26: /* anonymous */(aka /* anonymous */) [0x3a340812eda1] [internal/main/run_main_module.js:17] [bytecode=0x3a34083014e5 offset=61](this=0x3a340804030d <undefined>,0x3a34080c213d <process map = 0x3a340825a7a1>#4#,0x3a34080c301d <JSFunction nativeModuleRequire (sfi = 0x3a3408296629)>#2#,0x3a34080c3ae1 <JSFunction internalBinding (sfi = 0x3a3408296709)>#5#,0x3a3408287121 <Object map = 0x3a34082412f1>#6#,0x3a3408301239 <JSFunction (sfi = 0x3a3408301211)>#20#)
   27: InternalFrame [pc: 0x55a4e984081a]
   28: EntryFrame [pc: 0x55a4e98405f8]

Workers, huh? I wonder what that's doing there (and why our code is in the middle of the stack). Ok, let's try a smaller piece of code:

let done = false;

function lala() {
  setInterval(lala, 150);
}
lala();
console.log('Ready');
==== JS stack trace =========================================

    0: ExitFrame [pc: 0x55b79756afff]
Security context: 0x1d1108280545 <JSObject>#0#
    1: /* anonymous */(aka /* anonymous */) [0x1d11081621b5] [tty.js:1] [bytecode=0x1d1108339e95 offset=-1](this=0x1d110804030d <undefined>,0x1d11080cd725 <Object map = 0x1d11082402d9>#1#,0x1d11080c301d <JSFunction nativeModuleRequire (sfi = 0x1d1108296629)>#2#,0x1d11080cd6e5 <NativeModule map = 0x1d1108244041>#3#,0x1d11080c213d <process map = 0x1d110825a7a1>#4#,0x1d11080c3ae1 <JSFunction internalBinding (sfi = 0x1d1108296709)>#5#,0x1d1108287121 <Object map = 0x1d11082412f1>#6#)
    2: compileForInternalLoader [0x1d11080c6151] [internal/bootstrap/loaders.js:276] [bytecode=0x1d1108299ea1 offset=112](this=0x1d11080cd6e5 <NativeModule map = 0x1d1108244041>#3#)
    3: nativeModuleRequire(aka nativeModuleRequire) [0x1d11080c301d] [internal/bootstrap/loaders.js:305] [bytecode=0x1d1108299d29 offset=79](this=0x1d110804030d <undefined>,0x1d11082fe4f5 <String[#3]: tty>)
    4: createWritableStdioStream(aka createWritableStdioStream) [0x1d110812d5c9] [internal/bootstrap/switches/is_main_thread.js:42] [bytecode=0x1d1108339c05 offset=68](this=0x1d110804030d <undefined>,1)
    5: getStdout [0x1d110812d609] [internal/bootstrap/switches/is_main_thread.js:118] [bytecode=0x1d11083398d9 offset=19](this=0x1d11080c213d <process map = 0x1d110825a7a1>#4#)
    6: StubFrame [pc: 0x55b79737a90f]
    7: StubFrame [pc: 0x55b7977b928d]
    8: get [0x1d1108118445] [internal/console/constructor.js:164] [bytecode=0x1d1108339785 offset=10](this=0x1d1108116f59 <Object map = 0x1d1108256e21>#7#)
    9: StubFrame [pc: 0x55b79737a90f]
   10: StubFrame [pc: 0x55b7977b928d]
   11: /* anonymous */ [0x1d11082e4205] [internal/console/constructor.js:286] [bytecode=0x1d11083396c1 offset=9](this=0x1d1108116f59 <Object map = 0x1d1108256e21>#7#,0x1d1108161fed <JSArray[1]>#8#)
   12: log [0x1d11081165a1] [internal/console/constructor.js:297] [bytecode=0x1d11083395ed offset=29](this=0x1d1108116f59 <Object map = 0x1d1108256e21>#7#)
   13: arguments adaptor frame: 1->0
   14: InternalFrame [pc: 0x55b79734881a]
   15: EntryFrame [pc: 0x55b7973485f8]
   16: builtin exit frame: consoleCall(this=0x1d1108116f59 <Object map = 0x1d1108256e21>#7#,0x1d1108336411 <String[#5]: Ready>,0x1d110811725d <JSBoundFunction (BoundTargetFunction 0x1d11081165a1)>#9#,0x1d110828ed39 <JSFunction log (sfi = 0x1d11081cfa31)>#10#,0x1d1108116f59 <Object map = 0x1d1108256e21>#7#)

   17: /* anonymous */ [0x1d1108150881] [/tmp/aa/fooo2.js:8] [bytecode=0x1d1108338041 offset=36](this=0x1d110814fde5 <Object map = 0x1d11082402d9>#11#,0x1d110814fde5 <Object map = 0x1d11082402d9>#11#,0x1d1108150b0d <JSFunction require (sfi = 0x1d1108337e15)>#12#,0x1d110814fced <Module map = 0x1d110825e8f1>#13#,0x1d110814f5e9 <String[16]: /tmp/aa/fooo2.js>,0x1d1108150aa1 <String[7]: /tmp/aa>)
   18: InternalFrame [pc: 0x55b79734881a]
   19: EntryFrame [pc: 0x55b7973485f8]
   20: builtin exit frame: callAndPauseOnStart(this=0x1d11080c0121 <JSGlobal Object>#14#,0x1d1108150aa1 <String[7]: /tmp/aa>,0x1d110814f5e9 <String[16]: /tmp/aa/fooo2.js>,0x1d110814fced <Module map = 0x1d110825e8f1>#13#,0x1d1108150b0d <JSFunction require (sfi = 0x1d1108337e15)>#12#,0x1d110814fde5 <Object map = 0x1d11082402d9>#11#,0x1d110814fde5 <Object map = 0x1d11082402d9>#11#,0x1d1108150881 <JSFunction (sfi = 0x1d11083364a1)>#15#,0x1d11080c0121 <JSGlobal Object>#14#)

   21: _compile [0x1d1108323cdd] [internal/modules/cjs/loader.js:1201] [bytecode=0x1d1108335821 offset=417](this=0x1d110814fced <Module map = 0x1d110825e8f1>#13#,0x1d110815075d <String[129]\: let done = false;\n\nfunction lala() {\n  // process._rawDebug('hey oh');\n  setInterval(lala, 150);\n}\nlala();\nconsole.log('Ready');\n>,0x1d110814f5e9 <String[16]: /tmp/aa/fooo2.js>)
   22: .js [0x1d1108323d09] [internal/modules/cjs/loader.js:1224] [bytecode=0x1d1108333099 offset=155](this=0x1d1108147f91 <Object map = 0x1d1108242629>#16#,0x1d110814fced <Module map = 0x1d110825e8f1>#13#,0x1d110814f5e9 <String[16]: /tmp/aa/fooo2.js>)
   23: load [0x1d1108323c85] [internal/modules/cjs/loader.js:1053] [bytecode=0x1d110833267d offset=189](this=0x1d110814fced <Module map = 0x1d110825e8f1>#13#,0x1d110814f5e9 <String[16]: /tmp/aa/fooo2.js>)
   24: _load [0x1d1108323c45] [internal/modules/cjs/loader.js:948] [bytecode=0x1d1108330ec1 offset=403](this=0x1d11081359a5 <JSFunction Module (sfi = 0x1d110830950d)>#17#,0x1d1108134d45 <String[16]: /tmp/aa/fooo2.js>,0x1d1108040171 <null>,0x1d11080403e5 <true>)
   25: runMain(aka executeUserEntryPoint) [0x1d110814ebd5] [internal/modules/run_main.js:71] [bytecode=0x1d110832e075 offset=86](this=0x1d11081359a5 <JSFunction Module (sfi = 0x1d110830950d)>#17#,0x1d1108134d45 <String[16]: /tmp/aa/fooo2.js>)
   26: /* anonymous */(aka /* anonymous */) [0x1d110812eda1] [internal/main/run_main_module.js:17] [bytecode=0x1d11083014e5 offset=61](this=0x1d110804030d <undefined>,0x1d11080c213d <process map = 0x1d110825a7a1>#4#,0x1d11080c301d <JSFunction nativeModuleRequire (sfi = 0x1d1108296629)>#2#,0x1d11080c3ae1 <JSFunction internalBinding (sfi = 0x1d1108296709)>#5#,0x1d1108287121 <Object map = 0x1d11082412f1>#6#,0x1d1108301239 <JSFunction (sfi = 0x1d1108301211)>#18#)
   27: InternalFrame [pc: 0x55b79734881a]
   28: EntryFrame [pc: 0x55b7973485f8]

Ok, now we are in TTY, apparently inside console.log? On another run I got the last frame being on net.js.

In both cases, the type of context_ is NATIVE_CONTEXT, which is why the DCHECK is failing (it's not a function or debug context). I'll go on a limb here and guess this has something to do with pausing withing a still-running require. Let's do some testing:

require("tty");
let done = false;

function lala() {
  setInterval(lala, 150);
}
lala();
console.log('Ready');

Well, this works. Let's try the other way around. The code above should break on Chrome DevTools:

// require-me.js
while (true) { }
require("./require-me");

Well, Chrome DevTools worked. I tried the same on a Node.js module and got the same result.

So, looking back at the output of jst. In the crashing script:

==== JS stack trace =========================================                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                                                  
    0: ExitFrame [pc: 0x55d12c53ecbf]                                                                                                                                                                                                                                             
Security context: 0x0bec08280545 <JSObject>#0#                                                                                                                                                                                                                                    
    1: /* anonymous */(aka /* anonymous */) [0xbec08162615] [net.js:1] [bytecode=0xbec0833ad51 offset=-1](this=0x0bec0804030d <undefined>,0x0bec080ccf71 <Object map = 0xbec082402d9>#1#,0x0bec080c3039 <JSFunction nativeModuleRequire (sfi = 0xbec08296629)>#2#,0x0bec080ccf31 <
NativeModule map = 0xbec08244041>#3#,0x0bec080c213d <process map = 0xbec0825a7a1>#4#,0x0bec080c3afd <JSFunction internalBinding (sfi = 0xbec08296709)>#5#,0x0bec08287121 <Object map = 0xbec082412f1>#6#)                                                                         
    2: compileForInternalLoader [0xbec080c616d] [internal/bootstrap/loaders.js:276] [bytecode=0xbec08299ea1 offset=112](this=0x0bec080ccf31 <NativeModule map = 0xbec08244041>#3#)                                                                                                

Notice the [bytecode=0xbec0833ad51 offset=-1]. I'm not sure, but I think the offset=-1 mean the code is not executing yet.

jst from a script with a while (true) {} in it (notice we have a positive offset this time):

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x557996d4ccbf]
    1: StubFrame [pc: 0x557996fee2c4]
Security context: 0x2e7b08280545 <JSObject>#0#
    2: /* anonymous */(aka /* anonymous */) [0x2e7b0817e061] [os.js:23] [bytecode=0x2e7b0836b2cd offset=147](this=0x2e7b0804030d <undefined>,0x2e7b080cd049 <Object map = 0x2e7b082402d9>#1#,0x2e7b080c308d <JSFunction nativeModuleRequire (sfi = 0x2e7b08296629)>#2#,0x2e7b080cd
009 <NativeModule map = 0x2e7b08244041>#3#,0x2e7b080c213d <process map = 0x2e7b0825a7a1>#4#,0x2e7b080c3b51 <JSFunction internalBinding (sfi = 0x2e7b08296709)>#5#,0x2e7b08287121 <Object map = 0x2e7b082412f1>#6#)
    3: compileForInternalLoader [0x2e7b080c61c1] [internal/bootstrap/loaders.js:276] [bytecode=0x2e7b08299ea1 offset=112](this=0x2e7b080cd009 <NativeModule map = 0x2e7b08244041>#3#)

This gives me an idea to break --inspect. If we console.log inside session.on("pause,, we'll be lazily loading Let's try it:

// crash-without-brk.js
const { Session } = require('inspector');
const session = new Session();
let done = false;

function lala() {
  setInterval(lala, 150);
  if (done)
    console.log('Ready');
}
lala();
session.on('Debugger.paused', () => {
  done = true;
});
session.connect();
session.post('Debugger.enable');

And boom!

$ node --inspect crash-without-brk.js
# after calling the websocket script

#
# Fatal error in ../../deps/v8/src/debug/debug-scopes.cc, line 452
# Debug check failed: current_scope_->NeedsContext() implies context_->IsFunctionContext() || context_->IsDebugEvaluateContext().
#
#
#
#FailureMessage Object: 0x7ffee58c22f0
 1: 0x56523d23cad4 node::DumpBacktrace(_IO_FILE*) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 2: 0x56523d3c6f1f  [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 3: 0x56523d3c6f43  [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 4: 0x56523ee3536b V8_Fatal(char const*, int, char const*, ...) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 5: 0x56523ee3539b  [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 6: 0x56523d79f48e v8::internal::ScopeIterator::Type() const [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 7: 0x56523d79d168 v8::internal::DebugScopeIterator::DebugScopeIterator(v8::internal::Isolate*, v8::internal::FrameInspector*) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 8: 0x56523d7a8878 v8::internal::DebugStackTraceIterator::GetScopeIterator() const [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
 9: 0x56523e11736b v8_inspector::V8DebuggerAgentImpl::currentCallFrames(std::unique_ptr<std::vector<std::unique_ptr<v8_inspector::protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> >, std::allocator<std::unique_ptr<v8_inspector::
protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> > > >, std::default_delete<std::vector<std::unique_ptr<v8_inspector::protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> >, std::alloc
ator<std::unique_ptr<v8_inspector::protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> > > > > >*) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
10: 0x56523e11ee77 v8_inspector::V8DebuggerAgentImpl::didPause(int, v8::Local<v8::Value>, std::vector<int, std::allocator<int> > const&, v8::debug::ExceptionType, bool, bool, bool) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
11: 0x56523e1063d0  [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
12: 0x56523e128d01 v8_inspector::V8InspectorImpl::forEachSession(int, std::function<void (v8_inspector::V8InspectorSessionImpl*)> const&) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
13: 0x56523e1097ff v8_inspector::V8Debugger::handleProgramBreak(v8::Local<v8::Context>, v8::Local<v8::Value>, std::vector<int, std::allocator<int> > const&, v8::debug::ExceptionType, bool) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
14: 0x56523d7bf06d v8::internal::Debug::OnDebugBreak(v8::internal::Handle<v8::internal::FixedArray>) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
15: 0x56523d7bf24b v8::internal::Debug::HandleDebugBreak(v8::internal::IgnoreBreakMode) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
16: 0x56523d5850eb v8::debug::BreakRightNow(v8::Isolate*) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
17: 0x56523d854939 v8::internal::Isolate::InvokeApiInterruptCallbacks() [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
18: 0x56523d881012 v8::internal::StackGuard::HandleInterrupts() [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
19: 0x56523de7aafb  [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
20: 0x56523de7ae8e v8::internal::Runtime_StackGuard(int, unsigned long*, v8::internal::Isolate*) [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
21: 0x56523e48ccbf  [/home/mmarchini/workspace/nodejs/node-v8/out/Debug/node]
[1]    11135 illegal hardware instruction (core dumped)  /home/mmarchini/workspace/nodejs/node-v8/out/Debug/node --inspect crash-without-brk.js

This is all accetonal evidence, but it leads me to believe the issue is manifesting when we call pause and a recently loaded script is in an intermediate state (it's not running yet, but it was at least parsed, probably compiled and loaded on the stack).

</details>

targos

comment created time in a day

issue openednodejs/node-v8

`./configure --debug` not working without `--experimental-enable-pointer-compression`

$ ./configure --debug
Node.js configure: Found Python 3.7.5...
INFO: configure completed successfully

$ make -j32 BUILDTYPE=Debug -C out/
...
  TOUCH db289bf03238b5b9fbfd145a08c728f10a435a3f.intermediate
  ACTION generating: "/home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/obj.target/v8_zlib/geni/snapshot.cc" "/home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/obj.target/v8_zlib/geni/embedded.S" db289bf03238b5b9fbfd145a08c728f10a435a3f.intermediate


#
# Fatal error in ../deps/v8/src/codegen/x64/assembler-x64.h, line 123
# Debug check failed: SmiValuesAre31Bits().
#
#
#
#FailureMessage Object: 0x7fffc67ccf10
==== C stack trace ===============================

    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(v8::base::debug::StackTrace::StackTrace()+0x12) [0x55ae6bcf2f72]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(+0x127007a) [0x55ae6af5707a]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(V8_Fatal(char const*, int, char const*, ...)+0x17b) [0x55ae6af4d13b]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(+0x126616b) [0x55ae6af4d16b]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(v8::internal::Builtins::Generate_InterpreterEntryTrampoline(v8::internal::MacroAssembler*)+0xaa2) [0x55ae6ba30ae2]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(+0x182f8ce) [0x55ae6b5168ce]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(v8::internal::SetupIsolateDelegate::SetupBuiltinsInternal(v8::internal::Isolate*)+0x996) [0x55ae6b517876]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(v8::internal::SetupIsolateDelegate::SetupBuiltins(v8::internal::Isolate*)+0x58) [0x55ae6af44728]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(v8::internal::Isolate::Init(v8::internal::ReadOnlyDeserializer*, v8::internal::StartupDeserializer*)+0x1166) [0x55ae6a5420c6]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(v8::SnapshotCreator::SnapshotCreator(v8::Isolate*, long const*, v8::StartupData*)+0xfd) [0x55ae6a3c803d]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(v8::internal::CreateSnapshotDataBlobInternal(v8::SnapshotCreator::FunctionCodeHandling, char const*, v8::Isolate*)+0x4d) [0x55ae6aa4d3dd]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(main+0x2bc) [0x55ae6a3b0adc]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f2cff9141e3]
    /home/mmarchini/workspace/nodejs/node-v8-lala/out/Debug/mksnapshot(_start+0x2e) [0x55ae6a3bc3ae]
Illegal instruction (core dumped)
make: *** [tools/v8_gypfiles/v8_snapshot.target.mk:17: db289bf03238b5b9fbfd145a08c728f10a435a3f.intermediate] Error 132
rm 789e532d012df1d22207d570710447c224257f33.intermediate 14c5b9873273637da0c069b6f6e7e03ae83559fc.intermediate 377a8ebb7c015d9afd89119f3cc53cd93545cecb.intermediate db289bf03238b5b9fbfd145a08c728f10a435a3f.intermediate
make: Leaving directory '/home/mmarchini/workspace/nodejs/node-v8-lala/out'

With --experimental-enable-pointer-compression it works though.

created time in a day

issue commentnodejs/node-v8

Failing test: test-inspector-multisession-ws

FYI, I'm looking into this (couldn't find any PRs referencing this issue, so I assume no one fixed it yet). The child process (the process being inspected) is segfaulting when it receives a Debugger.pause. I was able to reproduce this outside test with:

// script.js
const { Session } = require('inspector');
const session = new Session();
let done = false;
const interval = setInterval(() => {
  process._rawDebug('hey oh');
  if (done)
    clearInterval(interval);
}, 1000);
session.on('Debugger.paused', () => {
  done = true;
});
session.connect();
session.post('Debugger.enable');
console.log('Ready');
// connect.js
'use strict'

const http = require("http");
const WebSocket = require('ws');

function usage() {
  console.error('USAGE: node index.js <PID>')
  process.exit(1)
}

if (process.argv.length !== 3) usage();

const pid = Number(process.argv[2])

if (pid === NaN) usage();

let first = true;

function connectToInspector(url) {
  const ws = new WebSocket(url);

  ws.on('message', function incoming(data) {
    const res = JSON.parse(data);
    if (first && res.method == "Debugger.paused") {
      first = false;
      ws.send(JSON.stringify({"method": "Debugger.resume", "id": 4}));
    }
    if (res.method == "Debugger.resumed")
      ws.send(JSON.stringify({"method": "Debugger.pause", "id": 3}));
    if (res.method != "Debugger.scriptParsed")
      console.log(res);
  });

  ws.on('open', function open() {
    ws.send(JSON.stringify({"method": "Debugger.enable", "id": 1}));
    ws.send(JSON.stringify({"method": "Runtime.runIfWaitingForDebugger", "id": 2}));
  });
}

function getWebSocketPath(cb) {
  http.get("http://localhost:9229/json", (resp) => {
    let data = '';

    resp.on('data', (chunk) => {
      data += chunk;
    });

    resp.on('end', () => cb(JSON.parse(data)[0].webSocketDebuggerUrl));
  })
}

process.kill(pid, 'SIGUSR1');
getWebSocketPath(connectToInspector);
$ node --inspect-brk script.js &
[1] 13214
Debugger listening on ws://127.0.0.1:9229/6680ec92-a986-4a8c-8f2f-0daee5deabfb                                                           
For help, see: https://nodejs.org/en/docs/inspector

$ node connect.js $(pgrep node)
Debugger attached.
{
  id: 1,
  result: { debuggerId: '-5779516113788299134.3822508824226157107' }
}
{ id: 2, result: {} }
{
  method: 'Debugger.paused',
  params: {
    callFrames: [
      [Object], [Object],
      [Object], [Object],
      [Object], [Object],
      [Object]
    ],
    reason: 'Break on start',
    hitBreakpoints: []
  }
}
{ id: 4, result: {} }
{ method: 'Debugger.resumed', params: {} }
{ id: 3, result: {} }
[1]  + 14390 segmentation fault (core dumped)  /home/mmarchini/workspace/nodejs/node-v8/node --inspect-brk fooo.js

Stack from core dump:

* thread #1, name = 'node', stop reason = signal SIGSEGV
  * frame #0: 0x0000564beda33b47 node`v8::internal::ScopeIterator::Type() const + 55
    frame #1: 0x0000564beda321c0 node`v8::internal::DebugScopeIterator::Advance() + 48
    frame #2: 0x0000564bee052d44 node`v8_inspector::V8DebuggerAgentImpl::currentCallFrames(std::unique_ptr<std::vector<std::unique_ptr<v8_inspector::protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> >, std::allocator<std::unique_ptr<v8_inspector::protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> > > >, std::default_delete<std::vector<std::unique_ptr<v8_inspector::protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> >, std::allocator<std::unique_ptr<v8_inspector::protocol::Debugger::CallFrame, std::default_delete<v8_inspector::protocol::Debugger::CallFrame> > > > > >*) + 2404
    frame #3: 0x0000564bee059fca node`v8_inspector::V8DebuggerAgentImpl::didPause(int, v8::Local<v8::Value>, std::vector<int, std::allocator<int> > const&, v8::debug::ExceptionType, bool, bool, bool) + 1386
    frame #4: 0x0000564bee04185a node`std::_Function_handler<void (v8_inspector::V8InspectorSessionImpl*), v8_inspector::V8Debugger::handleProgramBreak(v8::Local<v8::Context>, v8::Local<v8::Value>, std::vector<int, std::allocator<int> > const&, v8::debug::ExceptionType, bool)::'lambda0'(v8_inspector::V8InspectorSessionImpl*)>::_M_invoke(std::_Any_data const&, v8_inspector::V8InspectorSessionImpl*&&) + 170
    frame #5: 0x0000564bee064314 node`v8_inspector::V8InspectorImpl::forEachSession(int, std::function<void (v8_inspector::V8InspectorSessionImpl*)> const&) + 452
    frame #6: 0x0000564bee044abf node`v8_inspector::V8Debugger::handleProgramBreak(v8::Local<v8::Context>, v8::Local<v8::Value>, std::vector<int, std::allocator<int> > const&, v8::debug::ExceptionType, bool) + 511
    frame #7: 0x0000564beda44386 node`v8::internal::Debug::OnDebugBreak(v8::internal::Handle<v8::internal::FixedArray>) + 486
    frame #8: 0x0000564beda44530 node`v8::internal::Debug::HandleDebugBreak(v8::internal::IgnoreBreakMode) + 384
    frame #9: 0x0000564bed945f0d node`v8::debug::BreakRightNow(v8::Isolate*) + 45
    frame #10: 0x0000564beda877e3 node`v8::internal::Isolate::InvokeApiInterruptCallbacks() + 163
    frame #11: 0x0000564bedaa007d node`v8::internal::StackGuard::HandleInterrupts() + 557
    frame #12: 0x0000564bede60e9d node`v8::internal::Runtime_StackGuard(int, unsigned long*, v8::internal::Isolate*) + 109
    frame #13: 0x0000564bee1c06d9 node`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit + 57
    frame #14: 0x0000564bee159213 node`Builtins_InterpreterEntryTrampoline + 307
    frame #15: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #16: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #17: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #18: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #19: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #20: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #21: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #22: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #23: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #24: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #25: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #26: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #27: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #28: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #29: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #30: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #31: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #32: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #33: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #34: 0x0000564bee156dfa node`Builtins_JSEntryTrampoline + 90
    frame #35: 0x0000564bee156bd8 node`Builtins_JSEntry + 120
    frame #36: 0x0000564beda724ae node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 446
    frame #37: 0x0000564beda732f7 node`v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 119
    frame #38: 0x0000564bed931863 node`v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) + 323
    frame #39: 0x0000564bed84e22e node`node::inspector::(anonymous namespace)::CallAndPauseOnStart(v8::FunctionCallbackInfo<v8::Value> const&) + 382
    frame #40: 0x0000564bed98c17f node`v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) + 367
    frame #41: 0x0000564bed98c540 node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(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) + 208
    frame #42: 0x0000564bed98cdda node`v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) + 266
    frame #43: 0x0000564bed98d68a node`v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) + 26
    frame #44: 0x0000564bee1c07b9 node`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 57
    frame #45: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #46: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #47: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #48: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #49: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #50: 0x0000564bee15919e node`Builtins_InterpreterEntryTrampoline + 190
    frame #51: 0x0000564bee156dfa node`Builtins_JSEntryTrampoline + 90
    frame #52: 0x0000564bee156bd8 node`Builtins_JSEntry + 120
    frame #53: 0x0000564beda724ae node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 446
    frame #54: 0x0000564beda732f7 node`v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 119
    frame #55: 0x0000564bed931863 node`v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) + 323
    frame #56: 0x0000564bed71a0fa node`node::ExecuteBootstrapper(node::Environment*, char const*, std::vector<v8::Local<v8::String>, std::allocator<v8::Local<v8::String> > >*, std::vector<v8::Local<v8::Value>, std::allocator<v8::Local<v8::Value> > >*) + 138
    frame #57: 0x0000564bed71afc3 node`node::StartExecution(node::Environment*, char const*) + 483
    frame #58: 0x0000564bed71b657 node`node::StartMainThreadExecution(node::Environment*) + 1511
    frame #59: 0x0000564bed7988fd node`node::NodeMainInstance::Run() + 557
    frame #60: 0x0000564bed71d92b node`node::Start(int, char**) + 251
    frame #61: 0x00007efe201aa1e3 libc.so.6`__libc_start_main(main=(node`main), argc=3, argv=0x00007fffa32fa788, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffa32fa778) at libc-start.c:308
    frame #62: 0x0000564bed67803e node`_start + 46

Interestingly enough, this only happens with --inspect-brk -> Debugger.resume -> Debugger.pause. --inspect -> Debugger.pause works just fine. And even more interesting, if I connect Chrome DevTools to node --inspect-brk script.js, resume and pause afterwards, it doesn't crash.

I'll keep investigating and share any results I find.

targos

comment created time in a day

PR closed nodejs/llnode

meta: add policy to land PRs without approval

As discussed in the 2020-02-12 Diagnostics WG Meeting and suggested in https://github.com/nodejs/llnode/issues/242#issuecomment-430369666, change the landing policy so that Collaborators can land pull requests if it was open for three days and there were no reviews on it.

Ref: https://github.com/nodejs/diagnostics/issues/355

+3 -0

3 comments

1 changed file

mmarchini

pr closed time in a day

pull request commentnodejs/llnode

meta: add policy to land PRs without approval

Landed in bd3a1c7eac4c

mmarchini

comment created time in a day

push eventnodejs/llnode

Matheus Marchini

commit sha bd3a1c7eac4c8455b7a17ff4b6c53a3234a89fe2

meta: add policy to land PRs without approval As discussed in the 2020-02-12 Diagnostics WG Meeting and suggested in https://github.com/nodejs/llnode/issues/242#issuecomment-430369666, change the landing policy so that Collaborators can land pull requests if it was open for three days and there were no reviews on it. Ref: https://github.com/nodejs/diagnostics/issues/355 PR-URL: https://github.com/nodejs/llnode/pull/336 Refs: https://github.com/nodejs/diagnostics/issues/355 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

push time in a day

pull request commentnodejs/node

build: add flag to enable pointer compression

@targos any concerns on backporting this to v12.x? I was testing it today, and if we add the following lines (pulled from dda658cc0f785563fa847061cfd598a054de6420) to common.gypi, it works:

diff --git a/common.gypi b/common.gypi
index 8c9076b735..856c6aa6ff 100644
--- a/common.gypi
+++ b/common.gypi
@@ -339,6 +339,12 @@
           }],
         ],
       }],
+      ['v8_enable_pointer_compression == 1', {
+        'defines': ['V8_COMPRESS_POINTERS'],
+      }],
+      ['v8_enable_pointer_compression == 1 or v8_enable_31bit_smis_on_64bit_arch == 1', {
+        'defines': ['V8_31BIT_SMIS_ON_64BIT_ARCH'],
+      }],
       ['OS == "win"', {
         'defines': [
           'WIN32',

The changes are non-intrusive, since it only impacts builds using --experimental-enable-pointer-compression. I can send a PR to backport it, unless there are other concerns.

mcollina

comment created time in 2 days

issue commentNetflix/flamescope

add an upload endpoint

An upload endpoint is probably a good idea. I would rather have it as upload -> process -> return flamegraph instead of saving the file to disk. Not sure what others think.

ramonf-garcia

comment created time in 2 days

pull request commentnodejs/node

cli: --perf-prof only works on Linux

--perf-prof doesn't make much sense on outside of Linux, as it generates a jitdump file.

--perf-basic-prof on the other hand could be used on other platforms, since it is just a text file (I have used it on OS X in the past). Well, that's not really a Node.js issue though. I'll get in touch with V8 about that.

codebytere

comment created time in 2 days

issue closednodejs/node

lldb jlh command has stopped working

  • Version: v13.0.0-pre
  • Platform: Darwin MBP-1206.lan 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64
  • Subsystem: v8

The lldb command jlh has stopped working for me. At the moment this is what happens if I run it:

(lldb) jlh arg

(The output is just a blank line). The expected output in this case would be:

(lldb) jlh arg
#undefined

Looking at lldb_commands.py this cast seems to be the issue, at least for the jlh command and removing it fixes the issue for me.

I know that we don't maintain lldb_commands.py but I wanted to ask if anyone else has run into this before looking into it closer and perhaps opening an issue upstream.

closed time in 3 days

danbev

issue commentnodejs/node

lldb jlh command has stopped working

V8 doesn't use heap classes as pointers to the heap anymore. Instead, those classes are concrete C++ objects with a ptr_ field. This was part of a larger initiative to make V8 UBSAN-compliant, the commits which lead to this change can be seen in the tracking issue: https://bugs.chromium.org/p/v8/issues/detail?id=3770&q=3770&can=2. Design document to move from object pointers to concrete objects can be found here: https://docs.google.com/document/d/1_w49sakC1XM1OptjTurBDqO86NE16FH8LwbeUAtrbCo/edit#heading=h.8wg7tpqbpt7m

I'll close this as answered, but feel free to reopen if you want.

danbev

comment created time in 3 days

push eventmmarchini/mmarchini.github.io

Matheus Marchini

commit sha ded922f277d0aa828e547f13384e42ca7888ea90

update info

view details

push time in 3 days

Pull request review commentnodejs/diagnostics

doc: add inspector document

-// TODO+# Using Inspectors++Inspectors are very useful on development. It allow us to step into our+programs and get our hands on every slice of our code and values of its+local variables.++## Attach to the Running Process++Normally, Node.js process will not open inspector port for listening+inspector client connections. We can send a signal `SIGUSR1` to the running+process and then the inspector will start listening for new debugger+connections.

Worth mentioning that you can start the process with a specific port open. This should probably come first, leaving the SIGUSR1 as a secondary approach (especially since it doesn't work on Windows)

legendecas

comment created time in 4 days

Pull request review commentnodejs/diagnostics

doc: add inspector document

-// TODO+# Using Inspectors++Inspectors are very useful on development. It allow us to step into our

s/Inspectors/Chrome DevTools/

legendecas

comment created time in 4 days

Pull request review commentnodejs/diagnostics

doc: add inspector document

-// TODO+# Using Inspectors++Inspectors are very useful on development. It allow us to step into our+programs and get our hands on every slice of our code and values of its+local variables.+

Add a paragraph mentioning that the Inspector is built to be production safe, as long as properly used (which means not connecting Chrome Devtools to a production instance). Later we can add a link on this paragraph to a new session "Using the Inspector Protocol in production"

legendecas

comment created time in 4 days

pull request commentnodejs/diagnostics

doc: add inspector document

Also, I think this guide should be retitled as Using Chrome DevTools

legendecas

comment created time in 4 days

issue commentnodejs/TSC

De-charter Benchmark WG

We'll need some volunteers to help with whatever we decided to keep around.

I can help with that. Maybe we should keep the @nodejs/benchmarking team around then, so that others can ping when there are benchmark-related issues?

mhdawson

comment created time in 5 days

issue commentnodejs/llnode

Introducing bison as a dependency

#314 has a draft parser for .attribute and [0-9], it doesn't take into account things like ["foo bar"]. I'm also sure it has bugs, because I implemented it as a proof-of-concept only.

For findjsinstances queries, we could have a complex grammar with !, &&, ||, ==, !=, etc., in which case the parser would probably be over 200 lines. Not sure if we want something so complex though. Maybe focusing on finishing the JS API would also cover the use cases for queries in findjsinstances.

mmarchini

comment created time in 5 days

issue commentnodejs/TSC

De-charter Benchmark WG

That's unfortunate, but completely understandable. I was going to ask to join the WG now that I'm back from vacation.

Is there any way we can keep benchmarking.nodejs.org up, even with the WG de-chartered?

mhdawson

comment created time in 5 days

issue commentnodejs/llnode

PSA: repository tracking V8 postmortem changes

The problem with tests to detect metadata change is that they might not run every command (if a test step fail, for example), and ::Load is only called when needed (so some Constants classes would never be called).

mmarchini

comment created time in 5 days

issue openednodejs/llnode

`v8 bt` segfaults on latest V8

The bug is not on llnode, but it breaks v8 bt, so I'm keeping this open to track. lldb GetDescription broken on latest V8 without pointer compression. Not sure where to fix it, but we should probably mitigate on llnode as well

created time in 5 days

pull request commentnodejs/llnode

meta: add policy to land PRs without approval

Keeping this open until tomorrow afternoon (PST) in case there are any objections from folks who didn't comment yet

mmarchini

comment created time in 5 days

pull request commentnodejs/node

tools: add NODE_TEST_NO_INTERNET to the doc builder

Shouldn't it fail if NODE_TEST_NO_INTERNET is set on a release build? It seems like the environment variable allows users to bypass that check now

joyeecheung

comment created time in 5 days

issue openednodejs/llnode

Introducing bison as a dependency

For two features I have in mind (arbitrary accessors #314 and queries for findjsinstances #334) it would be useful to have a lexer/parser integrated on llnode. One of the most popular is bison. Introducing it as a dependency without carrying that to our users can be tricky, but I think it can be done if:

  1. we only require bison for development
  2. when publishing, we generate .cc files from the lexical definitions and upload those to npm

Does anyone have objections on introducing bison as dependency?

created time in 5 days

issue commentnodejs/llnode

PSA: repository tracking V8 postmortem changes

We could even improve the code on that repository to also print all symbols llnode is able to load from a d8 binary. If there are changes in this list between two versions, those changes will likely impact llnode.

This could be implemented on llnode as:

  1. Keep a cache of all symbols successfully loaded
  2. Expose a command (could be available only on debug) to run ::Load on all Constants classes and output that list
mmarchini

comment created time in 6 days

issue commentnodejs/llnode

PSA: repository tracking V8 postmortem changes

On llnode-v8-tester. My idea is to use information from issues there to open issues here manually, after triaging which metadata change are relevant for llnode.

mmarchini

comment created time in 6 days

issue commentnodejs/llnode

PSA: repository tracking V8 postmortem changes

cc @cjihrig as this might be of your interest

mmarchini

comment created time in 6 days

issue openednodejs/llnode

PSA: repository tracking V8 postmortem changes

I created a repository to keep track of V8 postmortem metadata changes (https://github.com/mmarchini/llnode-v8-tester). The repository uses daily GitHub Actions to build d8 and will create an issue every time metadata changes are detected. In the future I hope to add some llnode integration tests there as well (run llnode test suite against the latest build of d8).

This is not intended to replace the postmortem tests we have on Node.js, so we should keep updating those as we introduce new metadata here.

created time in 6 days

PublicEvent

issue commentnodejs/llnode

Command to find object by key/value pair

Just came across a real world example where this would be useful: find all ServerResponse objects where .statusCode=400. I imagine finding requests/responses based on field values is a common use case when debugging servers.

mmarchini

comment created time in 6 days

PR opened nodejs/llnode

tools: add script with commands to facilitate dev

Some tasks are very common when working on llnode, especially when upgrading a V8 version. This new script is intended to make developers life easier by simplifying tasks which usually require printfs on llnode code or manually inspecting the memory of a process. Hopefully we'll add more commands in the future.

+96 -0

0 comment

1 changed file

pr created time in 9 days

create barnchmmarchini/llnode

branch : dev-helpers

created branch time in 9 days

issue openednodejs/llnode

Tests should work with d8

Except for Node.js specific features (v8 workqueue), tests should work with d8 as well. Maybe they do, but I never tried it, so I'm opening this issue to investigate.

created time in 10 days

issue openednodejs/llnode

Warnings should not be emitted if constant is expected to be missing

Some constants are expected to be missing in some versions, but they'll warn anyway. This is problematic because it pollutes the warnings, making it harder to know when a constant is actually missing. Missing constants should still warn when they are expected to be missing, but they should fail silently otherwise.

created time in 10 days

Pull request review commentnodejs/llnode

meta: add policy to land PRs without approval

 with the following differences:   - There's no minimum wait time for landing a pull request. Pull requests can     land as soon as they get approved by at least one Collaborator.   - Approval must be from Collaborators who are not authors of the change.+  - If the pull request was open for three days (72 hours) without reviews, and

I'm not entirely opposed to 7 days, but I don't think "to match the one approval clause from core" is a good reason to do so. I'm open to hearing other arguments to use 7 days instead of 3 though.

On a counter-argument to 7 days, if there is a bug and a PR with a fix doesn't get a review, it will now take seven days to release a fix. We could have a shorter waiting period for bug fixes, but that seems to overly complicate the policy.

mmarchini

comment created time in 10 days

push eventmmarchini/diagnostics

Matheus Marchini

commit sha 9ef3431b1904bfc954403aae6e3cf7643cf954ed

fixup Co-Authored-By: Colin Ihrig <cjihrig@gmail.com>

view details

push time in 11 days

startedosandov/drgn

started time in 11 days

pull request commentnodejs/llnode

meta: add policy to land PRs without approval

cc @nodejs/diagnostics @nodejs/llnode @nodejs/post-mortem please let me know if there are any objections

mmarchini

comment created time in 11 days

PR opened nodejs/llnode

meta: add policy to land PRs without approval

As discussed in the 2020-02-12 Diagnostics WG Meeting and suggested in https://github.com/nodejs/llnode/issues/242#issuecomment-430369666, change the landing policy so that Collaborators can land pull requests if it was open for three days and there were no reviews on it.

Ref: https://github.com/nodejs/diagnostics/issues/355

+3 -0

0 comment

1 changed file

pr created time in 11 days

create barnchmmarchini/llnode

branch : land-without-approval

created branch time in 11 days

issue closednodejs/diagnostics

Node.js Foundation Diagnostics WorkGroup Meeting 2020-01-29

Time

UTC Wed 29-Jan-2020 17:30 (05:30 PM):

Timezone Date/Time
US / Pacific Wed 29-Jan-2020 09:30 (09:30 AM)
US / Mountain Wed 29-Jan-2020 10:30 (10:30 AM)
US / Central Wed 29-Jan-2020 11:30 (11:30 AM)
US / Eastern Wed 29-Jan-2020 12:30 (12:30 PM)
London Wed 29-Jan-2020 17:30 (05:30 PM)
Amsterdam Wed 29-Jan-2020 18:30 (06:30 PM)
Moscow Wed 29-Jan-2020 20:30 (08:30 PM)
Chennai Wed 29-Jan-2020 23:00 (11:00 PM)
Hangzhou Thu 30-Jan-2020 01:30 (01:30 AM)
Tokyo Thu 30-Jan-2020 02:30 (02:30 AM)
Sydney Thu 30-Jan-2020 04:30 (04:30 AM)

Or in your local time:

  • http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Diagnostics%20WorkGroup+Meeting+2020-01-29&iso=20200129T17
  • or http://www.wolframalpha.com/input/?i=05PM+UTC%2C+Jan+29%2C+2020+in+local+time

Links

Agenda

Extracted from diag-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/diagnostics

  • reportVersion semantics are not defined #349
  • Proposal to drive Diagnostics WG initiatives through user journeys #295
  • Diagnostics "Best Practices" Guide? #211
  • [async_hooks] stable API - tracking issue #124

Invited

  • Diagnostics team: @nodejs/diagnostics

Observers/Guests

Notes

The agenda comes from issues labelled with diag-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

  • link for participants: https://zoom.us/j/466707925
  • For those who just want to watch:
  • youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

closed time in 11 days

mhdawson

push eventnodejs/diagnostics

Michael Dawson

commit sha a95350d4509d174bfda05fc806109bbe74bedcbd

doc: add minutes for meeting 29 Jan 2020 PR-URL: https://github.com/nodejs/diagnostics/pull/352 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>

view details

push time in 11 days

PR opened nodejs/diagnostics

doc: add minutes for meeting 2020-02-12

Closes: https://github.com/nodejs/diagnostics/issues/354

+77 -0

0 comment

1 changed file

pr created time in 11 days

push eventmmarchini/diagnostics

Matheus Marchini

commit sha 78a925f70f8125d30e3b00f1db68ea4ada0490e3

doc: add minutes for meeting 2020-02-12 Closes: https://github.com/nodejs/diagnostics/issues/354

view details

push time in 11 days

create barnchmmarchini/diagnostics

branch : minutes-2020-02-12

created branch time in 11 days

issue commentnodejs/diagnostics

Node.js Foundation Diagnostics WorkGroup Meeting 2020-02-12

I forgot we changed the meeting time. Might join a few minutes late

mhdawson

comment created time in 11 days

issue openednodejs/llnode

Make the V8-related code lldb-agnostic

Most of the code we have on llnode doesn't have to be tied to lldb. We use lldb entirely for memory access (either on a core dump or living process). If we separate the code, providing an interface that can be implemented, we could provide multiple backends for llnode. For example, we could keep the lldb build and provide a smaller build in Webassembly using libelf and our own REPL to read the core dump (this would improve installation for users quite a bit).

created time in 11 days

issue commentnodejs/diagnostics

Future of llnode

Adding this to the agenda so we can discuss it further tomorrow.

mmarchini

comment created time in 12 days

issue openednodejs/diagnostics

Future of llnode

I've raised this topic before, but I think it's still a problem, so I'm raising it again, now with a slightly different perspective.

llnode is moving slow. Slower than it should. And slower than it's healthy for the project. For llnode to stay relevant, it needs to keep up with V8 and Node.js, two fast paced projects. It should minimally keep up with Node.js LTS releases.

llnode doesn't have many contributors, which is understanding. The project is complex and requires frequently reading V8 source code. We tried to promote the project in the past to get more attention. It didn't work. At most we got some style-related (linter, etc.) contributions, which are not very helpful in our case because it only increases the burden on current maintainers to review. Which brings us to the next point.

Reviewers frequency fell over the past two years. The current state of things is (mostly): one person contributing with code, another person reviewing code in src/, and another person reviewing build-related code. Since the project is not a priority to most folks, reviews will take time. For small PRs, reviews might come faster. But for larger PRs it can take months and several pings.

I noticed that trend, so for the v12 currency I tried to break all changes into the smallest PRs possible, to make review easier. Still took a while to get review on the first few PRs, and then reviews stopped coming. In the end I gave up, closed the small PRs, opened one huge PR with all remaining changes for v12 currency, and escalated the reviews request to the WG. While this worked, it's not sustainable to escalate every PR to the WG. It also doesn't make much sense, since most folks here are not familiar with llnode's code base.

In the current state, the whole review process ends up being demotivating and draining. I proposed this before, but I think we should drop the review process for llnode, as it's not really adding anything meaningful for the project and is preventing it from moving forward.

I'm proposing this again because I got my motivation to work on llnode back and have some extra cycles I can use for that. There are many things I want to do which will improve the project reliability and usability (for example: add ASAN/UBSAN builds to our CI, standardize output, move JS API out of experimental, allow accessors with property names and array indexes, etc.). I also intend to keep llnode up to speed with at least Node.js master.

If removing reviews is not possible, I'll likely fork the project (either under @mmarchini/llnode or a new name on npm) so it can move faster.

created time in 12 days

issue commentnodejs/llnode

llnode don't support nodejs v12

Closing as llnode 3.0.0 supports Node.js v12.x

phantom9999

comment created time in 12 days

issue commentnodejs/llnode

Command to find object by key/value pair

More sophisticated queries would also be interesting, for example: find all objects with value "bar" in key foo and without the key biz.

mmarchini

comment created time in 13 days

issue openednodejs/llnode

Command to find object by key/value pair

Similar to v8 findrefs -n, but it would take a property name and the value. This can help narrow down the search when there's a lot of objects, but we're looking only for those with a particular value.

created time in 13 days

issue closednodejs/node

Request timeout if a single header exceeds the max-http-header-size limit

  • Version: 10.15.1
  • Platform: 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
  • Subsystem: http

If a request header exceeds the max-http-header-size in Node 10.15.1 and 10.15.0 the request hangs leaving the socket open until the server times out. This seems like it could be a potential DoS attack vector. On Node 10.14.1 a 400 response is received as expected. The code below demonstrates the issue. If you run the code on 10.14.1 both requests will return immediately with a 400 as expected. On 10.15.1 the second request times out.

You can grab the test script from here also. https://github.com/natedanner/node-max-header-timeout/blob/master/server.js

const http = require('http');
const port = 3000;

const server = http.createServer((req, res) => {
	res.writeHead(200, {'Content-Type': 'text/plain; charset=UTF-8'});
	res.end('Hello World\n');
})

server.listen(port, () => {
	console.log(`Listening on ${port}`);

	// Headers that together exceed default 8k limit
	const defaultHeaders = {
		'FOO': '6'.repeat(8100),
		'BAR': '6'.repeat(8192)
	};
	
	function callServer(callerName, headers) {
		return http.get('http://localhost:3000', { headers }, (response) => {
			console.log(callerName, 'responded with:', response.statusCode);
		});
	}
	
	const excessHeadersRequest = callServer('EXCESS_HEADER', defaultHeaders);
	excessHeadersRequest.setTimeout(2000, () => {
		console.log('SHOULD NOT SEE THIS');
	});

	// If you exceed header limit on a single header by 1 then the request hangs open
	defaultHeaders['BAR'] += '6'
	const headerTimeoutRequest = callServer('EXCESS_HEADER_TIMEOUT', defaultHeaders);
	headerTimeoutRequest.setTimeout(2000, () => {
		console.log('EXCESS_HEADER_TIMEOUT CALL TIMED OUT!');
	});
});

closed time in 16 days

natedanner

issue commentnodejs/node

Request timeout if a single header exceeds the max-http-header-size limit

Ok, so I tried on v10.14.0, v10.15.1 and v10.15.3, and v10.19.0 the issue seems resolved on 10.15.3 and onwards.

$ nvm use 10.14.0
Now using node v10.14.0 (npm v6.4.1)

$ node index.js
Listening on 3000
EXCESS_HEADER responded with: 400
EXCESS_HEADER_TIMEOUT responded with: 400
^C

$ nvm install 10.15.1
Now using node v10.15.1 (npm v6.4.1)

$ node index.js
Listening on 3000
EXCESS_HEADER responded with: 400
EXCESS_HEADER_TIMEOUT CALL TIMED OUT!
^C

$ nvm install 10.15.3
Now using node v10.15.3 (npm v6.4.1)

$ node index.js
Listening on 3000
EXCESS_HEADER responded with: 400
EXCESS_HEADER_TIMEOUT responded with: 400
^C

$ nvm install 10.19.0
Now using node v10.19.0 (npm v6.13.4)

$ node index.js
Listening on 3000
EXCESS_HEADER responded with: 400
EXCESS_HEADER_TIMEOUT responded with: 400

Based on that, I'm closing this issue. Feel free to reopen if I missed something though.

natedanner

comment created time in 16 days

issue commentnodejs/node

Request timeout if a single header exceeds the max-http-header-size limit

I believe this was fixed on 10.15.3 (although I haven't tested it). Can this issue be closed?

natedanner

comment created time in 17 days

PR opened nodejs/nodejs.org

fix(blog): point v10.19.0 to the correct URL

URL for v10.19.0 changelog was broken (pointing to unreleased v10.19.1).

+1 -1

0 comment

1 changed file

pr created time in 17 days

push eventmmarchini/nodejs.org

Matheus Marchini

commit sha b17fb968fe1757f5d9765af3bbac3975d13f7312

fix(blog): point v10.19.0 to the correct URL URL for v10.19.0 changelog was broken (pointing to unreleased v10.19.1).

view details

push time in 17 days

pull request commentsthima/libstapsdt

Support for memory-backed file description

Great! I might take a few weeks to get to it though. Just got back from vacation and I'm on a few conferences now, so my backlog is quite huge. Will try to prioritize it though, as it's a nice addition :)

dalehamel

comment created time in 17 days

PR opened tc39/notes

Add Matheus Marchini (MAR)
+1 -0

0 comment

1 changed file

pr created time in 18 days

push eventmmarchini/notes

Matheus Marchini

commit sha d154838ea2a1aa29e020e27f3ed98d4d0db36fce

Add Matheus Marchini (MAR)

view details

push time in 18 days

release nodejs/llnode

v3.0.0

released time in a month

created tagnodejs/llnode

tagv3.0.0

An lldb plugin for Node.js and V8, which enables inspection of JavaScript states for insights into Node.js processes and their core dumps.

created time in a month

issue commentnodejs/llnode

Wrong instance_size?

I'll have to take a closer look to answer your questions (I'm going on vacation today, so I'll try to answer it when I'm back around late-Feb)

hyj1991

comment created time in a month

PR closed nodejs/llnode

src: harden SlicedString::ToString

Add some extra checks to make sure we won't crash when stringifying a (possibly corrupted) SlicedString.

+3 -1

2 comments

1 changed file

mmarchini

pr closed time in a month

pull request commentnodejs/llnode

src: harden SlicedString::ToString

Landed in bff9f5ea3e75

mmarchini

comment created time in a month

push eventnodejs/llnode

Matheus Marchini

commit sha bff9f5ea3e75607c7828bab04f87c2dfc03a5dcd

src: harden SlicedString::ToString Add some extra checks to make sure we won't crash when stringifying a (possibly corrupted) SlicedString. PR-URL: https://github.com/nodejs/llnode/pull/332 Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

view details

push time in a month

PR closed nodejs/llnode

Nodejs v12 support

This PR contains all commits necessary to make llnode work on v12, plus changes to CI to run tests on v12, drop v8 and v11, and bump the major version since we're dropping support and adding new one. I made a PR on nodejs/node to update the list of postmortem constants used, but I noticed some of the constants here already changes on v13, so we'll have to work on that.

+514 -207

2 comments

12 changed files

mmarchini

pr closed time in a month

pull request commentnodejs/llnode

Nodejs v12 support

Landed in 878b514e2919...e8896e0d3932

mmarchini

comment created time in a month

push eventnodejs/llnode

Matheus Marchini

commit sha 1faa8809151cb168f29706b62389118941bd9fa8

src: v12.x-compatible DescriptorArray V8 changed DescriptorArray from a FixedArray to a proper HeapObject. These changes update accessors for DescriptorArray fields to make them compatible with FixedArray-like and HeapObject-like access. Ref: https://github.com/nodejs/llnode/issues/255 PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha 2cc07cd0cb28fea55f5143336a47e3b0f78476ea

test: skip inferredName on 12 V8 changed the function name inference algorithm, which affected one of our test cases. Even if it's reverted/fixed upstream, it won't make it's way into v12, so skip that particular test for this version. Ref: https://bugs.chromium.org/p/v8/issues/detail?id=9807 PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha f8eebcc98bea633c85011542f3e101b493b9cc27

src: v12 fixed for JSArrayBuffer & FixedTypedArray PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha 5a94ecf9c678c7ef157ad9845ce8767b9661182c

src: handle String__FIELD_offset__int Some Node.js v12 versions will have String postmortem metadata as `String__FIELD_offset__int` instead of `String__FIELD_offset__TYPE`. Handle both cases so llnode can work on more versions. PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha 1b8f143369234eb101959a868f9de61c76df9163

src: make Symbol more resilient Instead of crashing if llnode fails to parse a Symbol, just return a ??? token. PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha b30cf41a1777875b3c9a55d1ee0ddf7404e91306

src: use 24 as default for kHeaderSize PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha c981f7fce1bf30cbf0d2e52dd1c20dbac28c18f8

src: guess Symbol.name offset PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha b0fa68ceed42e24bc3f21fac28d452dfd12a25f7

build: update Node.js versions on CI matrix PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

Matheus Marchini

commit sha e8896e0d39321478311ee5c259976f5b6a98bb07

3.0.0 PR-URL: https://github.com/nodejs/llnode/pull/330 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

view details

push time in a month

issue commentnodejs/diagnostics

Improving automated remote connection via Inspector Protcol

I don't think I agree. Implementing the limitations on the client side means only users using that particular client will be barred from using privileged features on the inspector protocol. Any other clients will be able to bypass it, since the inspector protocol is just an exchange of Websocket messages.

If we want to make the inspector protocol more secure, we need to allow the process being debugged to determine which inspector features are allowed and which ones are denied.

(maybe we are saying the same thing. Yes, we should be able to connect to a process with limited functionality. But who determines what is limited should not be client, otherwise an attacker would be able to always connect to a process with unlimited access)

mmarchini

comment created time in a month

issue commentnodejs/llnode

Wrong instance_size?

When the code gets here it should already be a v8::Map, but maybe we're missing some corner case here. JS_MAP_TYPE should fall under https://github.com/nodejs/llnode/blob/master/src/printer.cc#L655. Did you hit an issue with it? If so, can you share a small snippet with a reproducible (or more info)?

(JS_MAP_TYPE is https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map, right? If so, it's probably worth having a class dedicated for it)

hyj1991

comment created time in a month

pull request commentiovisor/bpftrace

Consider a non null-terminated and/or short Type::string value

LGTM, but I think we should add some tests for this.

Also, how does it interact with --format json? Are the warnings suppressed? We probably don't want warnings when the output is being processed by another program.

mmisono

comment created time in a month

issue openediovisor/bpftrace

Document `--format` option

--format (https://github.com/iovisor/bpftrace/blob/master/src/main.cpp#L43) is not documented in https://github.com/iovisor/bpftrace/blob/master/docs/reference_guide.md#usage or https://github.com/iovisor/bpftrace/blob/master/man/man8/bpftrace.8

created time in a month

pull request commentnodejs/node

process: allow monitoring uncaughtException

@Flarna thank you for working on this! It seems like the right direction to monitor uncaught exceptions on third-party monitoring tools.

Just a minor nit on the PR description: Installing an uncaughtException listener has a side effect that process is not aborted, when I first read it, I thought this PR was referring to --abort-on-uncaught-exception. Do you mind changing the description to Installing an uncaughtException listener has a side effect that process won't exit to avoid confusion when others read it?

Flarna

comment created time in a month

push eventnodejs/diagnostics

legendecas

commit sha 72151d6ebeee648b83b06c42b85d214e725688c4

doc: add abnormal termination step 1 Confirming if the process was exited for proactive invocation of `process.exit`. PR-URL: https://github.com/nodejs/diagnostics/pull/344 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Matheus Marchini <mat@mmarchini.me> Reviewed-By: Gerhard Stöbich <@Flarna>

view details

push time in a month

PR merged nodejs/diagnostics

doc: add abnormal termination step 1

Confirming if the process was exited for proactive invocation of process.exit.

The option is available after https://github.com/nodejs/node/pull/30516 has been landed.

+45 -1

2 comments

1 changed file

legendecas

pr closed time in a month

pull request commentfastify/benchmarks

bench: allow users to run benchmarks non-interactively

Will do when I'm back from vacation

mmarchini

comment created time in a month

issue commentnodejs/diagnostics

Make --prof toggleable

--prof is a V8 flag, so for those interested in this feature the best place to request it is in the V8 issue tracker: https://bugs.chromium.org/p/v8/issues/list.


@kwasimensah thera are a few alternatives to --prof if you need to profile your code on demand (without startup):

  1. You can use the Inspector Protocol to trigger V8 CPU Profile and open the output on Chrome DevTools. This can be achieved either with the Inspector API, npm modules like thetool, or completely on-demand connecting to the Inspector Protocol websocket and exchanging messages (I'm not aware of any guides for this last one though)
  2. You can use the C++ API to trigger a V8 CPU Profile. This is essentially the same as 1, but it uses the C++ API instead of the Inspector Protocol. There's probably an npm module with bindings for this
  3. If you are on Linux, you can use Linux perf in combination with --interpreted-frames-native-stack and --perf-basic-prof flags, as described here: https://nodejs.org/en/docs/guides/diagnostics-flamegraph/
davidmarkclements

comment created time in a month

issue commentnodejs/TSC

Looking for feedback: Pointer compression in Node.js

It seems there is a problem with pointer compression and one of the flags that can be used to profile Node.js applications: https://bugs.chromium.org/p/v8/issues/detail?id=10138. It's probably worth checking if other tools are affected before enabling pointer compression by default on our releases (if we decide to do so).

addaleax

comment created time in a month

issue commentnodejs/diagnostics

Improving automated remote connection via Inspector Protcol

Agreed, security should be taken into account, but that should be solved on the server/main-process side (and it's probably worth its own issue), otherwise we would still be able to bypass security with a raw websocket client.

mmarchini

comment created time in a month

Pull request review commentiovisor/bpftrace

Runtime feature checking

 int main(int argc, char *argv[])   {     switch (c)     {+      case 2000:+        std::cerr << BPFfeature().report();+        return 1;

Why return 1?

fbs

comment created time in a month

Pull request review commentiovisor/bpftrace

Runtime feature checking

 #include <iostream>  #include "irbuilderbpf.h"-#include "libbpf.h" #include "bcc_usdt.h" #include "arch/arch.h" #include "utils.h"  #include <llvm/IR/Module.h> +namespace libbpf {+#undef __BPF_FUNC_MAPPER+#include "libbpf/bpf.h"

Nice, I never thought about namespacing an include :)

fbs

comment created time in a month

pull request commentiovisor/bpftrace

Runtime feature checking

By defining this enum ourselves we avoid all those issues and make sure the symbol we need are always present.

Maybe we should try to look for kernel headers and use our clang parser to get the enum for the current kernel, and then fallback to our pre-defined enum otherwise? This can be a follow up though.

This will cause some issues if the kernel people ever decide to significantly change this enum (e.g. sorting it) but that seems unlikely and will cause a lot of issues anyway (e.g. codegen).

Codegen will still work after a rebuild.


Would it be viable for the kernel to provide another way to get the enum (from /sys/kernel, for example)?

fbs

comment created time in a month

pull request commentnodejs/llnode

src: harden SlicedString::ToString

I had this issue in the wild. Couldn't come up with a test case for it though...

mmarchini

comment created time in a month

PR opened nodejs/llnode

src: harden SlicedString::ToString

Add some extra checks to make sure we won't crash when stringifying a (possibly corrupted) SlicedString.

+3 -1

0 comment

1 changed file

pr created time in a month

create barnchmmarchini/llnode

branch : llnode-fix-scan

created branch time in a month

PR closed nodejs/llnode

src: v12.x-compatible DescriptorArray priority

V8 changed DescriptorArray from a FixedArray to a proper HeapObject. These changes update accessors for DescriptorArray fields to make them compatible with FixedArray-like and HeapObject-like access.

Ref: https://github.com/nodejs/llnode/issues/255

+137 -71

4 comments

7 changed files

mmarchini

pr closed time in a month

pull request commentnodejs/llnode

src: v12.x-compatible DescriptorArray

Superseded by #330

mmarchini

comment created time in a month

pull request commentnodejs/llnode

Nodejs v12 support

cc cc @nodejs/llnode @nodejs/diagnostics

mmarchini

comment created time in a month

push eventmmarchini/node

Rich Trott

commit sha 46ed24791c863cc9c6442b9a9c5cb17c3b130603

doc: standardize on "host name" in async_hooks.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 03d039349e64371089b8af3e5ccd899fa5bf0479

doc: standardize on "host name" in deprecations.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha b477c9504d3d6ac34124cbe7b2efc4e6c0f3025d

doc: standardize on "host name" in dgram.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha b3605ab6a310b95830a5bb0c500dd42f3c2b7b4a

doc: standardize on "host name" in errors.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 83909e04c0b9e985a84a15301f9021d00226d859

doc: standardize on "host name" in fs.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha ac887f849ae0597ccda49149b33715397ae99993

doc: standardize on "host name" in http2.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 278442eacb907537b2d9c5c718cde3bba095af84

doc: standardize on "host name" in https.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 57ac09cac79d80a5b064ffffbef7ee033ddcf934

doc: standardize on "host name" in net.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 7a4c9f14dcebc035ae4377ce309c319c2974afaf

doc: standardize on "host name" in os.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 342a89f09d6e1d06c1583f9b66ae9fb326803bab

doc: standardize on "host name" in tls.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Rich Trott

commit sha 2bb85b85c94465246841c8f4bcd73a6bec0917a6

doc: standardize on "host name" in url.md Our docs have a mix of "hostname" and "host name" in prose. Let's follow the usage of Unix man pages, RFCs, and most professionally-edited sources, and use "host name" in prose and "hostname" to refer to the command and in code. Lint rule forthcoming. PR-URL: https://github.com/nodejs/node/pull/31326 Refs: https://github.com/nodejs/node/pull/31073 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

bcoe

commit sha 521b2224c3b06de811f3d8353cce5e4a69239864

module: add API for interacting with source maps PR-URL: https://github.com/nodejs/node/pull/31132 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

view details

扩散性百万甜面包

commit sha 9da241b600182a9ff400f6efc24f11a6303c27f7

build: fix macos runner type in GitHub Action PR-URL: https://github.com/nodejs/node/pull/31327 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Minwoo Jung <nodecorelab@gmail.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

cjihrig

commit sha 216e42350f4fdfd4ae6c93b5569bc63327e823f3

deps: upgrade to libuv 1.34.1 Notable changes: - uv_fs_copyfile() now supports CIFS share destinations. - isatty() now works on IBMi - TTYs are opened with the O_NOCTTY flag. Fixes: https://github.com/nodejs/node/issues/31170 PR-URL: https://github.com/nodejs/node/pull/31332 Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

view details

Benjamin Coe

commit sha dcbf9da0edf9545107828784dbf3a59706411a3c

deps: V8: cherry-pick b9d33036e9a8 Original commit message: [coverage] Improve whitespace precision of coverage reporting This CL improves whitespace precision of coverage around try blocks; previously a small portion of whitespace could be reported as uncovered between try blocks and catch and/or finally blocks. Change-Id: I763ae3d15106c88f2278cf8893c12b0869a62528 Fixed: v8:10030 Bug: v8:10030 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962265 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#65593} Refs: https://github.com/v8/v8/commit/b9d33036e9a80fff87824f157f68928955842e66 PR-URL: https://github.com/nodejs/node/pull/31335 Refs: https://github.com/nodejs/node/issues/25937 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

Richard Lau

commit sha d830ff885d1eb67c5498d46c39da110c1341950b

build: add vs2019 to vcbuild.bat help PR-URL: https://github.com/nodejs/node/pull/31338 Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

Richard Lau

commit sha e67dc1e09f64b502642b2adcdf1b4bca6faaa4c9

build: remove enable_vtune from vcbuild.bat vcbuild.bat wasn't updated when vtune support was removed in https://github.com/nodejs/node/pull/28522 Refs: https://github.com/nodejs/node/pull/28522 PR-URL: https://github.com/nodejs/node/pull/31338 Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

Milad Farazmand

commit sha 578e4eddb97fffd6b9f1fe527da865875efa73f1

deps: V8: cherry-pick d89f4ef1cd62 Original commit message: S390x: improve performance by skipping Debug Hook if not needed Change-Id: Ib4b2821f2941cdc131f9c75b89a3baced7554f8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991802 Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65644} Refs: https://github.com/v8/v8/commit/d89f4ef1cd629cb169f0d9efcaefd05ebf09fd3d PR-URL: https://github.com/nodejs/node/pull/31354 Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>

view details

cjihrig

commit sha 38c07844b5d140a8f1f6902031559162625695b5

src: use uv_guess_handle() to detect TTYs This commit reverts https://github.com/nodejs/node/pull/30829 and uses uv_guess_handle() instead of isatty(). The IBMi changes are no longer required, as of libuv 1.34.1. PR-URL: https://github.com/nodejs/node/pull/31333 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: David Carlier <devnexen@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

cjihrig

commit sha b4f5c9e47a414585e80571a8933054badb911284

doc: add missing code formatting in vm.md This commit adds missing code formatting in a few places in the vm module documentation. PR-URL: https://github.com/nodejs/node/pull/31350 Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

view details

push time in a month

PR opened nodejs/node

test: update postmortem test with v12 constants

Ref: https://github.com/nodejs/llnode/pull/330

Checklist
  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] documentation is changed or added
  • [x] commit message follows commit guidelines
+4 -1

0 comment

1 changed file

pr created time in a month

PR closed nodejs/node

test: add promises metadata to postmortem test test

type_JSPromise__JS_PROMISE_TYPE and type_JSMessageObject__JS_MESSAGE_OBJECT_TYPE will be used on llnode to identify Promises in memory and core dumps: https://github.com/nodejs/llnode/pull/272. Add these to our postmortem test so we're aware of any changes to this metadata.

<!-- Thank you for your pull request. Please provide a description above and review the requirements below.

Bug fixes and new features should include tests and possibly benchmarks.

Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md -->

Checklist

<!-- Remove items that do not apply. For completed items, change [ ] to [x]. -->

  • [x] make -j4 test (UNIX), or vcbuild test (Windows) passes
  • [x] tests and/or benchmarks are included
  • [x] documentation is changed or added
  • [x] commit message follows commit guidelines

<!-- Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -->

+2 -0

5 comments

1 changed file

mmarchini

pr closed time in a month

push eventnodejs/node

Matheus Marchini

commit sha cf5624c4d8f16397c6d12aaf13bcc3ecfe10b8fe

test: add promises metadata to postmortem test type_JSPromise__JS_PROMISE_TYPE and type_JSMessageObject__JS_MESSAGE_OBJECT_TYPE will be used on llnode to identify Promises in memory and core dumps: https://github.com/nodejs/llnode/pull/272. Add these to our postmortem test so we're aware of any changes to this metadata. PR-URL: https://github.com/nodejs/node/pull/31357 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

view details

push time in a month

pull request commentnodejs/node

test: add promises metadata to postmortem test

Landed in cf5624c4d8f1

mmarchini

comment created time in a month

more