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

Overview

llnode

npm ci coverage

Node.js v10.x+ C++ plugin for the LLDB debugger.

The llnode plugin adds the ability to inspect JavaScript stack frames, objects, source code and more to the standard C/C++ debugging facilities when working with Node.js processes or core dumps in LLDB.

Demo

https://asciinema.org/a/29589

Quick start

Start an LLDB session with the llnode plugin automatically loaded:

npm install -g llnode
llnode `which node` -c /path/to/core/dump
  • Never install llnode with sudo as it can easily lead to errors during installation and execution.
  • For more details on starting llnode see the Usage section.
  • To get started with the llnode commands see the Commands section.

Install Instructions

Prerequisites: Official, active Node.js version

llnode only supports currently active Node.js versions installed via official channels. We recommend installing Node.js with nvm as it allows users to install global packages without sudo by default, and it always installs the official executables from https://nodejs.org.

Do not install Node.js from the default Ubuntu/Debian apt repositories (or from the default repositories of other Linux distributions), llnode is not compatible with Node.js installed that way. If you still want to install Node.js via apt-get, take a look at nodesource/distributions.

Prerequisites: Install LLDB and its Library

To use llnode you need to have the LLDB debugger installed. The recommended version is LLDB 3.9 and above.

  • OS X/macOS

    • You can install Xcode and use the LLDB that comes with it.

    • Optionally, you can install newer versions of lldb using Homebrew with

      brew update && brew install --with-lldb --with-toolchain llvm

      and make sure /usr/local/opt/llvm/bin gets searched before /usr/bin/ on your PATH. llnode will link to the LLDB installation returned by llvm-config if available.

  • Linux

    • You can install the lldb package using the package manager of your distribution. You may need to install additional packages for liblldb as well.

    • For example, on Ubuntu 16.04 you can install the prerequisites with

      apt-get install lldb-4.0 liblldb-4.0-dev
  • FreeBSD

    # Install llvm with lldb and headers
    pkg install llvm39
    rm -f /usr/bin/lldb
    ln -s /usr/local/bin/lldb39 /usr/bin/lldb
  • Windows

    • You can install a binary distribution of LLVM directly or using Chocolatey:

      cinst -y visualstudio2017buildtools visualstudio2017-workload-vctools llvm git

      Visual Studio is required for MSBuild and headers when building llnode. Git is required to download the lldb headers.

  • Android / Termux (Experimental)

    • Install Termux (https://termux.com)

    • Install Termux Packages

      • pkg install clang lldb lldb-dev make
      • pkg install nodejs-lts nodejs-lts-dev
    • To debug:

    llnode -- /data/data/com.termux/files/usr/bin/node --abort_on_uncaught_exception script.js
    (llnode) run
    

Install the Plugin

Install llnode globally via npm

If you have lldb available on your PATH, simply run:

npm install -g llnode

To build llnode against a specific lldb version matching an lldb executable, use the --lldb_exe npm option. For example, on Linux the executable on the PATH might be lldb-3.9:

npm install --lldb_exe=`which lldb-3.9` -g llnode

After installing with npm, llnode should be available on your PATH as a shortcut for running LLDB with the llnode plugin.

Optional: Install with Homebrew (OS X/macOS)

brew install llnode

Loading the llnode Plugin

There are several ways to load the llnode plugin:

1. Using the llnode shortcut

If you install llnode globally via npm (npm install -g llnode), you can use the llnode shortcut script. This starts lldb and automatically issues the plugin load command. All parameters to the llnode script are passed directly to lldb. If you it's not a local installation, the shortcut will be in node_modules/.bin/llnode.

2. Using ~/.lldbinit to load the Plugin Automatically

To tell LLDB to load llnode automatically regardless of the version of lldb that you are running, add this line to ~/.lldbinit:

plugin load /path/to/the/llnode/plugin

The path to the llnode plugin should be printed when the installation is finished. On OS X/macOS the plugin is typically node_modules/llnode/llnode.dylib, on Linux it's node_modules/llnode/llnode.so.

3. Loading the Plugin Manually

The llnode plugin can also be manually loaded into LLDB using the plugin load command within lldb.

It does not matter whether the plugin load command is issued before or after loading a core dump or attaching to a process.

4. Install the Plugin to the LLDB System Plugin Directory

Similar to the ~/.lldbinit approach, this way LLDB will also load the plugin automatically on start-up. Doing this may require additional permissions to be able to copy the plugin library to the system plugin directory.

On Linux, run make install-linux in the project directory, or if installing with npm, copy node_modules/llnode/llnode.so to /usr/lib/lldb/plugins or create a link there.

On OS X/macOS, run make install-osx in the project directory, or if installing with npm, copy node_modules/llnode/llnode.dylib to ~/Library/Application\ Support/LLDB/PlugIns/ or create a link there.

Usage

To use llnode with a core dump the core dump needs to be loaded into lldb along with the exact executable that created the core dump. The executable contains information that lldb and the llnode plugin need to make sense of the data in the core dump.

To load a core dump when starting llnode use:

llnode /path/to/bin/node -c /path/to/core

or to load the core dump after starting lldb:

(llnode) target create /path/to/bin/node -c /path/to/core

To use llnode against a live process:

llnode -- /path/to/bin/node script.js
(llnode) run

This is ideal for debugging an npm package with native code. To debug a Node.js crash on uncaught exception:

llnode -- /path/to/bin/node --abort_on_uncaught_exception script.js
(llnode) run

lldb will stop your process when it crashes. To see where it stopped use the v8 bt command. See the Commands section below for more commands.

Commands

(llnode) v8 help
     Node.js helpers

Syntax: v8

The following subcommands are supported:

      bt              -- Show a backtrace with node.js JavaScript functions and their args. An optional argument is accepted; if
                         that argument is a number, it specifies the number of frames to display. Otherwise all frames will be
                         dumped.

                         Syntax: v8 bt [number]
      findjsinstances -- List every object with the specified type name.
                         Use -v or --verbose to display detailed `v8 inspect` output for each object.
                         Accepts the same options as `v8 inspect`
      findjsobjects   -- List all object types and instance counts grouped by typename and sorted by instance count. Use
                         -d or --detailed to get an output grouped by type name, properties, and array length, as well as
                         more information regarding each type.
      findrefs        -- Finds all the object properties which meet the search criteria.
                         The default is to list all the object properties that reference the specified value.
                         Flags:

                          * -v, --value expr     - all properties that refer to the specified JavaScript object (default)
                          * -n, --name  name     - all properties with the specified name
                          * -s, --string string  - all properties that refer to the specified JavaScript string value

      getactivehandles  -- Print all pending handles in the queue. Equivalent to running process._getActiveHandles() on
                           the living process.

      getactiverequests -- Print all pending requests in the queue. Equivalent to running process._getActiveRequests() on
                           the living process.

      inspect         -- Print detailed description and contents of the JavaScript value.

                         Possible flags (all optional):

                          * -F, --full-string    - print whole string without adding ellipsis
                          * -m, --print-map      - print object's map address
                          * -s, --print-source   - print source code for function objects
                          * -l num, --length num - print maximum of `num` elements from string/array

                         Syntax: v8 inspect [flags] expr
      nodeinfo        -- Print information about Node.js
      print           -- Print short description of the JavaScript value.

                         Syntax: v8 print expr
      source list     -- Print source lines around the currently selected
                         JavaScript frame.
                         Syntax: v8 source list [flags]
                         Flags:
                         * -l <line> - Print source code below line <line>.

For more help on any particular subcommand, type 'help <command> <subcommand>'.

Develop and Test

Configure and Build

The easiest way to build the plugin:

# Clone this repo
git clone https://github.com/nodejs/llnode.git && cd llnode

# Configure and build the plugin with npm
npm install
# To configure and build the plugin without npm
node scripts/configure.js && node scripts/install.js && node scripts/cleanup.js
# Or use make
make plugin

# To configure and build both the plugin and the addon
npm install --llnode_build_addon=true
# To configure and build with a specific path to headers
npm install --llnode_lldb_include_dir=/path/to/lldb/include

# Without npm
LLNODE_BUILD_ADDON=true node scripts/configure.js && node scripts/install.js && node scripts/cleanup.js
# Or use make
make addon # Builds the addon
make       # Builds both the addon and the plugin

To configure the build yourself:

# Detect available lldb installation and download headers if necessary
node scripts/configure.js
# To build the addon, set the environment variable LLNODE_BUILD_ADDON=true

# To configure with the detected lldb installation
node-gyp configure
# To configure with a specified path to headers, where `$lldb_include_dir`
# contains the <lldb/*/*.h> headers
node-gyp configure -- -Dlldb_include_dir=/usr/local/Cellar/llvm/5.0.0/include
# To configure with a specified path to the libraries, where `$lldb_lib_dir`
# contains `liblldb.so` or `liblldb.dylib`
node-gyp configure -- -Dlldb_lib_dir=/usr/lib/llvm-3.9/lib

# Build the plugin (and the addon if LLNODE_BUILD_ADDON=true)
node-gyp build

# Move the built plugin to the project directory
node scripts/cleanup.js

Test

To run the tests, if lldb is an executable on the PATH:

npm run test-all    # Run both addon and plugin tests
npm run test-plugin # Run plugin tests
npm run test-addon    # Run addon tests

If the LLDB executable is named differently, point TEST_LLDB_BINARY to it before running the tests:

TEST_LLDB_BINARY=`which lldb-4.0` npm run test-all

Useful Environment Variables

  • LLNODE_DEBUG=true to see additional debug info from llnode
  • TEST_LLNODE_DEBUG=true to see additional debug info coming from the tests
  • LLNODE_CORE=/path/to/core/dump LLNODE_NODE_EXE=/path/to/node to use a prepared core dump instead of generating one on-the-fly when running the tests.

For example, to inspect the process of inspect-scenario.js, run:

LLNODE_DEBUG=true lldb -- \
  node --abort_on_uncaught_exception --expose_externalize_string \
  test/fixtures/inspect-scenario.js
(lldb) run

To debug test/scan-test.js with a prepared core dump:

LLNODE_DEBUG=true TEST_LLNODE_DEBUG=true \
  LLNODE_CORE=/path/to/core/dump/of/inspect/scenario.js \
  LLNODE_NODE_EXE=/path/to/node \
  node test/scan-test.js

LICENSE

This software is licensed under the MIT License.

Copyright Fedor Indutny, 2016.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Comments
  • README asks to install a seemingly incompatible lldb version

    README asks to install a seemingly incompatible lldb version

    Hi!

    The current llnode README documentation states that the lldb version to install is 3.8. Well... I copy/pasted the README installation instructions, but all I got when trying to load a coredump is another coredump from lldb.

    The coredump I try to load is generated by a process running either under node 4.6.1 or 6.9.1 (I tried both):

    $ lldb-3.8 node -c core
    (lldb) target create "node" --core "core"
    Segmentation fault (core dumped)
    

    Same thing happens with:

    • lldb 4.0
    • with or without llnode installed
    • with or without C++ node modules used by the project being coredumped
    • Debian Jessie and Ubuntu Xenial

    Note that gdb has no problem loading my coredumps files. Of course I can't do much with gdb. :-)

    It's when I stumbled upon this PR that I realized that you yourselves use lldb 3.6. So I tried that version, and now everything work fine.

    This issue is more about the README documentation than anything but, if needs be, I will be happy to provide any additional information you need to pinpoint where the problem is.

    opened by scottinet 25
  • readme: update Travis CI badge to reflect new github org

    readme: update Travis CI badge to reflect new github org

    For some reason the current badge doesn't work anymore. I'm not a hundred percent sure this is related to the move to the nodejs org, but in any case I guess this should be updated.

    I've also modified the URL slightly to reflect the latest conventions. Hopefully that's ok :)

    As far as I can see the builds have not been enabled on Travis yet, so this change will not work before someone on the Node.js org does that I guess.

    opened by watson 24
  • Is it possible to find all references to some object?

    Is it possible to find all references to some object?

    Hello,

    First, thank you for the job you've done, llnode is great debugging tool.

    mdb_v8 findjsobjects command has one useful feature:

    -r Find references to the specified and/or marked object(s)

    Is it possible to achieve the same with lldb + llnode? If not, do you have any plans to implement this feature?

    opened by unikoid 23
  • Upstream llnode to V8

    Upstream llnode to V8

    I recently had a chat with @indutny about llnode and concluded that upstreaming it to V8 might make sense. Let's start the discussion if it really makes sense and how it roughly could be accomplished.

    cc @ofrobots @bmeurer @hashseed

    opened by natorion 22
  • Use official `llvm-project` monorepo, expand LLDB versions check

    Use official `llvm-project` monorepo, expand LLDB versions check

    • Fetch headers from the official llvm-project instead of the deprecated llvm-mirror/lldb repo.
    • Check for LLDB versions 20.0 - 1.0.0 on Linux so we don't have to update LLDB versions for a few years.

    Fixes https://github.com/nodejs/llnode/issues/350

    opened by trxcllnt 19
  • changes to support Node.js v16 & v18

    changes to support Node.js v16 & v18

    With this diff, our tests are much better. Previously they were entirely failing on Node 16. Now:

    • stack-test passes (12/12)
    • inspect-test mostly passes (57/59)
    • frame-test somewhat passes (7/25)

    I marked the failing tests as skipped / optional.

    There are a couple of big commits in this diff. It is best reviewed commit-by-commit. They are in order:

    1. Postmortem data fixes

      • class_Map__constructor_or_backpointer__Object is now class_Map__constructor_or_back_pointer__Object (note the extra _).
      • class_Script__source__Object is weirdly not present in Node 16 but is present in both Node 14 and Node 18. I added a default to the correct value of 8.
    2. ScopeInfo is no longer a FixedArray as of v8/v8@ecaac329. The Length field was also removed in v8/v8@f731e13f.

      • The length field removal shifted everything over by a slot, meaning that a bunch of offsets changed.
      • Since ScopeInfo is no longer a FixedArray, I changed callsites to use HeapObject::LoadFieldValue rather than FixedArray::Get.
    3. Changes to V8 calling conventions

      • The arguments adapter frame no longer exists. Modified frame-test.js to match.
      • Arguments are no longer pushed "in reverse". Modified JSFrame::LeaParamSlot to match.
    4. A minor fix to nodejsVersion, which was returning [NaN] when run on a release build.

    5. Remove support for unboxed doubles, which fixes printing doubles since V8 broke our previous detection mechanism.

    6. Remove a couple of tests which seemed unnecessary (NativeModule and Promise).

    opened by kvakil 17
  • Unable to read all frames even V8 ones in core dump taken

    Unable to read all frames even V8 ones in core dump taken

    Hi I have been interested in debugging nodejs in prod for a while but having to install mdb was quite an issue, it’s really awesome that there is llnode.

    I installed llnode on my mac with brew for practice taking core dumps, analyzing points of failure etc it all worked, so I tried setting up with “a real project” using the simple code here so everything is predictable but with a docker container. The idea was to get the core dump move it to my machine and debugging, like I would hope to do in production

    This is what I got after moving it to my machine, I’d like to know what I might have done wrong

    screen shot 2017-04-11 at 2 35 14 pm
    opened by eokoneyo 17
  • npm install fails with Ubuntu 18.04, lldb 6.0

    npm install fails with Ubuntu 18.04, lldb 6.0

    e$ node-gyp -v
    v3.6.2
    ~$ dpkg -l lldb lldb-6.0-dev
    ii  lldb                                    1:6.0-41~exp5~ubuntu1    amd64                    Next generation, high-performance debugger
    un  lldb-6.0-dev                            
    

    fails "npm install" (w or without --debug):

    $ npm install --debug
    
    > [email protected] preinstall /home/jlevon/src/llnode
    > node scripts/configure.js
    
    Build dir is: /home/jlevon/src/llnode
    Looking for lldb executable...
    Found lldb executable /usr/bin/lldb
    
    Reading lldb version...
    Installing llnode for /usr/bin/lldb, lldb version 6.0
    
    Looking for llvm-config for lldb 6.0...
    Using llvm-config in /usr/bin/llvm-config-6.0
    
    Looking for headers for lldb 6.0...
    Found lldb headers in /usr/lib/llvm-6.0/include
    
    Looking for shared libraries for lldb 6.0...
    Found liblldb.so in /usr/lib/llvm-6.0/lib
    Writing config.gypi:
    {
      "variables": {
        "lldb_lib_dir%": "/usr/lib/llvm-6.0/lib",
        "lldb_lib%": "lldb",
        "lldb_include_dir%": "/usr/lib/llvm-6.0/include",
        "build_addon": "false",
        "coverage": "false"
      }
    }
    Writing llnode.js shortcut to /home/jlevon/src/llnode/llnode.js
    
    > [email protected] install /home/jlevon/src/llnode
    > node scripts/install.js
    
    make: Entering directory '/home/jlevon/src/llnode/build'
      CXX(target) Debug/obj.target/plugin/src/constants.o
      CXX(target) Debug/obj.target/plugin/src/error.o
      CXX(target) Debug/obj.target/plugin/src/llnode.o
      CXX(target) Debug/obj.target/plugin/src/llv8.o
    ../src/llv8.cc:732:36: warning: trigraph ??) ignored, use -trigraphs to enable [-Wtrigraphs]
       RETURN_IF_INVALID(name, "Symbol(???)");
                                         
    ../src/llv8.cc: In member function ‘llnode::v8::Value llnode::v8::JSObject::GetDescriptorProperty(std::__cxx11::string, llnode::v8::Map, llnode::Error&)’:
    ../src/llv8.cc:1179:14: warning: variable ‘value’ set but not used [-Wunused-but-set-variable]
           double value;
                  ^~~~~
      CXX(target) Debug/obj.target/plugin/src/llv8-constants.o
      CXX(target) Debug/obj.target/plugin/src/llscan.o
      CXX(target) Debug/obj.target/plugin/src/printer.o
    ../src/printer.cc: In member function ‘std::__cxx11::string llnode::Printer::Stringify(T, llnode::Error&) [with T = llnode::v8::JSArrayBuffer; Actual = llnode::v8::JSArrayBuffer; std::__cxx11::string = std::__cxx11::basic_string<char>]’:
    ../src/printer.cc:371:26: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
           if (display_length < *byte_length) {
               ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
    ../src/printer.cc: In member function ‘std::__cxx11::string llnode::Printer::Stringify(T, llnode::Error&) [with T = llnode::v8::JSTypedArray; Actual = llnode::v8::JSTypedArray; std::__cxx11::string = std::__cxx11::basic_string<char>]’:
    ../src/printer.cc:436:24: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
         if (display_length < *byte_length) {
             ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
    ../src/printer.cc: In member function ‘std::__cxx11::string llnode::Printer::Stringify(T, llnode::Error&) [with T = llnode::v8::Map; Actual = llnode::v8::Map]’:
    ../src/printer.cc:516:1: warning: control reaches end of non-void function [-Wreturn-type]
     }
     ^
      CXX(target) Debug/obj.target/plugin/src/node.o
      CXX(target) Debug/obj.target/plugin/src/node-constants.o
      CXX(target) Debug/obj.target/plugin/src/settings.o
      SOLINK(target) Debug/obj.target/plugin.so
      COPY Debug/lib.target/plugin.so
    make: Leaving directory '/home/jlevon/src/llnode/build'
    
    > [email protected] postinstall /home/jlevon/src/llnode
    > node scripts/cleanup.js
    
    Moving /home/jlevon/src/llnode/build/Debug/plugin.so to /home/jlevon/src/llnode/llnode.so
    fs.js:766
      return binding.rename(pathModule._makeLong(oldPath),
                     ^
    
    Error: ENOENT: no such file or directory, rename '/home/jlevon/src/llnode/build/Debug/plugin.so' -> '/home/jlevon/src/llnode/llnode.so'
        at Object.fs.renameSync (fs.js:766:18)
        at Object.<anonymous> (/home/jlevon/src/llnode/scripts/cleanup.js:26:4)
        at Module._compile (module.js:652:30)
        at Object.Module._extensions..js (module.js:663:10)
        at Module.load (module.js:565:32)
        at tryModuleLoad (module.js:505:12)
        at Function.Module._load (module.js:497:3)
        at Function.Module.runMain (module.js:693:10)
        at startup (bootstrap_node.js:188:16)
        at bootstrap_node.js:609:3
    

    I had to use this diff:

    $ git diff
    diff --git a/scripts/cleanup.js b/scripts/cleanup.js
    index 02fd591..98d839e 100644
    --- a/scripts/cleanup.js
    +++ b/scripts/cleanup.js
    @@ -15,7 +15,7 @@ if (osName === 'Darwin') {
     const llnodeLib = `plugin.${libExt}`;
     const destLib = `llnode.${libExt}`;
     
    -let buildPath = `${cwd}/build/Release/${llnodeLib}`;
    +let buildPath = `${cwd}/build/Release/lib.target/${llnodeLib}`;
     
     if (!fs.existsSync(buildPath))
       buildPath = `${cwd}/build/Debug/${llnodeLib}`;
    
    opened by jlevon 15
  • package.json: Make llnode installable via npm

    package.json: Make llnode installable via npm

    This updates package.json and adds scripts to allow llnode to be built via "npm install llnode" It doesn't create a Node.js module you can use via require('llnode'). (This may change in the future depending on project direction.)

    The npm name llnode has been reserved here: https://www.npmjs.com/package/llnode and Fedor also has access to that as discussed under issue #53.

    This PR does leave the npm version number at 0.0.0, this should be updated once the install process has been reviewed and at that point the llnode package should be npm publish'd.

    opened by hhellyer 15
  • findjsobjects

    findjsobjects

    Great work Fedor. Any idea whether it's possible within LLDB to find heap objects? Something along the lines of https://github.com/joyent/mdb_v8/blob/master/docs/usage.md#finding-javascript-objects would be extremely helpful.

    Actually, now that I think about it, what about porting some of the functionality over from mdb_v8 to lldb? The code for mdb_v8 is already open source, I wonder if it would be easier to try and port that library? In any case we should talk about your work with llnode here at an upcoming nodejs post mortem working group meeting.

    opened by yunong 15
  • Periodic test against master and canary

    Periodic test against master and canary

    I think we should have nightly/weekly test runs against master and canary. This would help us know earlier when something breaks. https://github.com/nodejs/node/pull/17685 was an awesome start, but as @bnoordhuis said in the PR it won't catch semantic changes.

    I'm willing to setup the infrastructure for it. I just need to know if we can have this on Travis (by using https://docs.travis-ci.com/user/cron-jobs/) or if we should introduce this on Node.js CI.

    /cc @joyeecheung

    enhancement meta 
    opened by mmarchini 14
  • no coverage for

    no coverage for "v8 nodeinfo"

    According to the coverage report there are no tests for v8 nodeinfo. Two options:

    1. Remove it. It is a couple hundred lines of code, and how often do you get a coredump where you don't know the version of Node.js you were running?
    2. Add a test for it.
    good first issue 
    opened by kvakil 4
  • bug(print-source): libc++abi: terminating with uncaught exception

    bug(print-source): libc++abi: terminating with uncaught exception

    Describe the bug llnode crashes when I run v8 i -s <addr>.

    To reproduce

    • Having this file crash.js
    'use strict';
    
    throw new Error('this is uncaught');
    
    • Running node --abort-on-uncaught-exception crash.js
    • Loaded core with llnode node/location -c core/location
    • Ran command v8 bt:
    (llnode) v8 bt
     * thread #1: tid = 0x0000, 0x0000000101756ca5 node`v8::base::OS::Abort() (.cold.1) + 5
      * frame #0: 0x0000000101756ca5 node`v8::base::OS::Abort() (.cold.1) + 5
        frame #1: 0x000000010147fa77 node`v8::base::OS::Abort() + 23
        frame #2: 0x00000001006e10bb node`v8::internal::Isolate::CreateMessageOrAbort(v8::internal::Handle<v8::internal::Object>, v8::internal::MessageLocation*) + 171
        frame #3: 0x00000001006e0aae node`v8::internal::Isolate::ThrowInternal(v8::internal::Object, v8::internal::MessageLocation*) + 958
        frame #4: 0x0000000100ae0ecf node`v8::internal::Runtime_Throw(int, unsigned long*, v8::internal::Isolate*) + 47
        frame #5: 0x0000000100e8b319 <exit>
        frame #6: 0x0000000100f20d5a <stub>
        frame #7: 0x0000000100e1ddea (this=0x2f03a76913e9:<Object: Object>, 0x2f03a76913e9:<Object: Object>, 0x2f03a7693201:<function: require at node:internal/modules/cjs/helpers:1:10>, 0x2f03a76911e1:<Object: Module>, 0x2f03a768f159:<String: "/Users/jamiamer/...">, 0x2f03a7693131:<String: "/Users/jamiamer/...">) at /Users/jamiamer/projects/llnode-tuto/simple-crash.js:1:0 fn=0x00002f03a7692e11
    ...
    
    • Ran command v8 i -s 0x2f03a7693201:
    • Crash.

    Expected behavior Having the source of the function printed in the console.

    Console output

    (llnode) v8 i -s 0x2f03a7693201
    libc++abi: terminating with uncaught exception of type std::out_of_range: basic_string
    PLEASE submit a bug report to https://developer.apple.com/bug-reporting/ and include the crash backtrace.
    Stack dump:
    0.	Program arguments: /Library/Developer/CommandLineTools/usr/bin/lldb --one-line "plugin load '/usr/local/Cellar/llnode/4.0.0/lib/node_modules/llnode/llnode.dylib'" --one-line "settings set prompt '(llnode) '" node -c /cores/core.1403
    Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
    0  lldb                     0x0000000100695357 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 39
    1  lldb                     0x0000000100694a85 llvm::sys::RunSignalHandlers() + 85
    2  lldb                     0x0000000100695a00 SignalHandler(int) + 288
    3  libsystem_platform.dylib 0x00007ff8174e6dfd _sigtramp + 29
    4  libsystem_platform.dylib 0x00007f7e00000400 _sigtramp + 18446743549332526624
    5  libsystem_c.dylib        0x00007ff81741cd24 abort + 123
    6  libc++abi.dylib          0x00007ff81748d082 abort_message + 241
    7  libc++abi.dylib          0x00007ff81747e1a5 demangling_terminate_handler() + 242
    8  libobjc.A.dylib          0x00007ff81737ae19 _objc_terminate() + 104
    9  libc++abi.dylib          0x00007ff81748c4a7 std::__terminate(void (*)()) + 8
    10 libc++abi.dylib          0x00007ff81748ed05 __cxa_get_exception_ptr + 0
    11 libc++abi.dylib          0x00007ff81748eccc __cxxabiv1::exception_cleanup_func(_Unwind_Reason_Code, _Unwind_Exception*) + 0
    12 libc++.1.dylib           0x00007ff817432a34 std::__1::__throw_out_of_range(char const*) + 56
    13 libc++.1.dylib           0x00007ff8174329fc std::__1::__throw_out_of_range(char const*) + 0
    14 libc++.1.dylib           0x00007ff817432c1d std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__throw_out_of_range() const + 9
    15 libc++.1.dylib           0x00007ff817433ae8 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, unsigned long, std::__1::allocator<char> const&) + 174
    16 llnode.dylib             0x00000001085614a7 llnode::v8::JSFunction::GetSource(llnode::Error&) + 975
    17 llnode.dylib             0x000000010857bcb2 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > llnode::Printer::Stringify<llnode::v8::JSFunction, llnode::v8::JSFunction>(llnode::v8::JSFunction, llnode::Error&) + 1970
    18 llnode.dylib             0x0000000108579140 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > llnode::Printer::Stringify<llnode::v8::HeapObject, llnode::v8::HeapObject>(llnode::v8::HeapObject, llnode::Error&) + 2464
    19 llnode.dylib             0x00000001085785a9 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > llnode::Printer::Stringify<llnode::v8::Value, llnode::v8::Value>(llnode::v8::Value, llnode::Error&) + 375
    20 llnode.dylib             0x00000001085561c6 llnode::PrintCmd::DoExecute(lldb::SBDebugger, char**, lldb::SBCommandReturnObject&) + 566
    21 LLDB                     0x0000000117ae28fa CommandPluginInterfaceImplementation::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) + 282
    22 LLDB                     0x0000000117cd57aa lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) + 410
    23 LLDB                     0x0000000117cca866 lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&) + 2278
    24 LLDB                     0x0000000117ccf458 lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 920
    25 LLDB                     0x0000000117bf6d3a lldb_private::IOHandlerEditline::Run() + 346
    26 LLDB                     0x0000000117bd9fdf lldb_private::Debugger::RunIOHandlers() + 143
    27 LLDB                     0x0000000117cd08ae lldb_private::CommandInterpreter::RunCommandInterpreter(lldb_private::CommandInterpreterRunOptions&) + 158
    28 LLDB                     0x0000000117afa61c lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 140
    29 lldb                     0x0000000100685668 Driver::MainLoop() + 2600
    30 lldb                     0x000000010068656b main + 2523
    31 dyld                     0x000000010867c52e start + 462
    

    Local environment (please complete the following information):

    • Version of llnode: 4.0.0
    • OS Info: Macbook pro (2015) - MacOs Monterey 12.5.1 (intel)
    • lldb Version: lldb-1400.0.30.3
    • Version of node.js: 16.17.0

    Server where the core was dumped (please complete the following information): Same as above.

    Additional context

    opened by tony-go 0
  • tests: Fix flaky JSArrayBuffer test

    tests: Fix flaky JSArrayBuffer test

    The JSArrayBuffer has failed in node 18 in lldb versions 8, 11, 13, 14 but when re-ran they all pass. It's not clear what is causing it so we have it to optional in this PR https://github.com/nodejs/llnode/pull/419

    Opening this to capture that it needs to be looked at and resolved if work is carried out in this area.

    opened by No9 3
  • refactor: use `debug_helper`

    refactor: use `debug_helper`

    Context

    As v8 API evolves and changes, we have to catch and handle breaking changes in the code.

    @kvakil suggest to use debug_helper in llnode see proposal.

    The debug module includes GetStackFrame and GetObjectProperties functions. Presumably, V8 would be receptive to patches to implement other functionality.

    Scope

    The main goal is to make llnode more maintainable in the mid/long term.

    • Reducing llnode's dependency with v8 API breaking changes
    • Documenting how to maintain debug_helper dependencies
    • Having a proper testing strategy

    Risks/Questions

    • List what is missing in debug_helper that we need in llnode
    • Estimate the amount of work to do in debug_helper
    • How to include debug_helper into llnode (as a dependency)
    opened by tony-go 0
  • discussion: Re-establish automation to detect breaking changes

    discussion: Re-establish automation to detect breaking changes

    As per https://github.com/nodejs/llnode/issues/287#issuecomment-1250090957 the core project used to detect breaking changes but this has been removed. This issue is to track conversation on how the llnode project can either re-establish the tests here or provide other mitigation.

    opened by No9 2
Releases(v4.0.0)
  • v4.0.0(Sep 14, 2022)

    What's Changed

    • changes to support Node.js v14 v16 & v18 by @kvakil in https://github.com/nodejs/llnode/pull/404
    • Support for earlier unsupported versions of node.js was dropped.

    New Contributors

    • @kvakil made their first contribution in https://github.com/nodejs/llnode/pull/404

    Full Changelog: https://github.com/nodejs/llnode/compare/v3.3.0...v4.0.0

    Source code(tar.gz)
    Source code(zip)
  • v3.3.0(Sep 14, 2022)

    What's Changed

    • Use official llvm-project monorepo, expand LLDB supported versions to 14 @trxcllnt in https://github.com/nodejs/llnode/pull/389
    • doc: add Node.js install instructions by @mmarchini in https://github.com/nodejs/llnode/pull/367
    • chore(ci): use codecov instead of coveralls by @mmarchini in https://github.com/nodejs/llnode/pull/371
    • chore(ci): temporarily disable OS X by @mmarchini in https://github.com/nodejs/llnode/pull/368
    • chore: add .mailmap by @mmarchini in https://github.com/nodejs/llnode/pull/369
    • scripts: remove unwanted require by @rickyes in https://github.com/nodejs/llnode/pull/359
    • chore: update master -> main by @mhdawson in https://github.com/nodejs/llnode/pull/392
    • chore(ci): fix CI by disabling nightly builds by @mmarchini in https://github.com/nodejs/llnode/pull/394
    • Update setup action to use latest version @No9 in https://github.com/nodejs/llnode/pull/398

    New Contributors

    • @rickyes made their first contribution in https://github.com/nodejs/llnode/pull/359
    • @mhdawson made their first contribution in https://github.com/nodejs/llnode/pull/392
    • @trxcllnt made their first contribution in https://github.com/nodejs/llnode/pull/389

    Full Changelog: https://github.com/nodejs/llnode/compare/v3.2.0...v3.3.0

    Source code(tar.gz)
    Source code(zip)
  • v3.2.0(May 4, 2020)

    Notable Changes

    • Added support for Node.js v14

    Commits

    • [4918962bee] - build: add v14 to the test matrix (Matheus Marchini) #361
    • [c86eb4356c] - src: update RegExp type constant for V8 8.1 (Matheus Marchini) #361
    • [dd57bfb8af] - src: boxed double fields for V8 8.1 (Matheus Marchini) #358
    • [fdddce0d2c] - doc: fix supported version comment on README (Matheus Marchini) #356
    • [7b9598e9da] - tools: git ignore core dumps (Matheus Marchini) #308
    • [8e2a55c82e] - src: update SFI script accessor for V8 8.1 (Matheus Marchini) #352
    • [364e034686] - src: fix some warnings and erroneous PRINT_DEBUG (Matheus Marchini) #354
    • [461e83aa0c] - src: improve Error message on LoadPtr (Matheus Marchini) #351
    • [1948512b5e] - tools: add script with commands to facilitate dev (Matheus Marchini) #339
    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Mar 27, 2020)

  • v3.0.0(Jan 21, 2020)

    Notable Changes

    • Drop support for lldb 3.8, Node.js v6.x, Node.js v8.x and Node.js v11.x
    • Add support for Node.js v12.x
    • Add recursive findrefs (v8 findrefs -r)
    • Several bug fixed
    • Robustness improvements: when llnode fails to read some fields or objects, it will render those values as ??? instead of failing to render the entire command (still a long way to go to get this behavior everywhere in the code)

    Commits

    • [bff9f5ea3e] - src: harden SlicedString::ToString (Matheus Marchini) #332
    • [b0fa68ceed] - build: update Node.js versions on CI matrix (Matheus Marchini) #330
    • [c981f7fce1] - src: guess Symbol.name offset (Matheus Marchini) #330
    • [b30cf41a17] - src: use 24 as default for kHeaderSize (Matheus Marchini) #330
    • [1b8f143369] - src: make Symbol more resilient (Matheus Marchini) #330
    • [5a94ecf9c6] - src: handle String__FIELD_offset__int (Matheus Marchini) #330
    • [f8eebcc98b] - src: v12 fixed for JSArrayBuffer & FixedTypedArray (Matheus Marchini) #330
    • [2cc07cd0cb] - test: skip inferredName on 12 (Matheus Marchini) #330
    • [1faa880915] - src: v12.x-compatible DescriptorArray (Matheus Marchini) #330
    • [878b514e29] - build: add project ncurc config (Matheus Marchini) #329
    • [8068cdad28] - src: fix function name lookup for inferred names (Matheus Marchini) #311
    • [82d28c5e26] - test: make SessionOutput Promise tolerant (Matheus Marchini) #311
    • [fd9d2b0990] - test: make func source test compatbile with v12 (Matheus Marchini) #326
    • [ecb8d0e342] - build: move CI to GitHub Actions (Matheus Marchini) #323
    • [6f27d84f3f] - test: use gdb to capture core on tests (Matheus Marchini) #323
    • [9a58d8cf3f] - build: allow custom lldb headers path with npm install (Matheus Marchini) #315
    • [f7f9347b19] - test: update Error.stack test for V8 7.5 (Matheus Marchini) #327
    • [37b3c26844] - src: use Check() instead of raw != -1 (Matheus Marchini) #313
    • [fde0c59cda] - src: update UncompiledData types constants (Matheus Marchini) #324
    • [2afd59edfb] - src: introduce Constant class (Matheus Marchini) #303
    • [ec016041c4] - src: fix source list on V8 7.4 (Matheus Marchini) #316
    • [a79a0084b6] - src: fix String::Length for Node.js v12.3.0 (Matheus Marchini) #302
    • [2964af57ff] - src: treat embeded builtins as V8 functions (Matheus Marchini) #301
    • [2c4c99cade] - src: use new SystemPointerSize constant (Matheus Marchini) #300
    • [fb25c910df] - src: fix JSError inspection with stringified stack (Matheus Marchini) #291
    • [9449d99f18] - src: improve messages on PrintInDebugMode (Matheus Marchini) #293
    • [a501635516] - src: improve Check() reliability (Matheus Marchini) #294
    • [0dbfad07e6] - src: fix findrefs for context locals (Matheus Marchini) #295
    • [84eefb4593] - src: fix gcc/clang warnings (Kirill Fomichev) #297
    • [afaec4825d] - doc: update collaborator guide to match the project size (Matheus Marchini) #296
    • [e1a74b0c97] - build: drop v6.x support (Matheus Marchini) #292
    • [13f7034046] - build: add tests for Node.js v11 (Matheus Marchini) #247
    • [ab2a7867a6] - src: fixes for V8 6.9 and 7.0 (Matheus Marchini) #247
    • [99d06e7cdb] - doc: add collaborator guide (Matheus Marchini) #275
    • [74414fc26a] - src: reduce redundant "error:" for inspect and findrefs (oyyd) #285
    • [640799a97e] - docs: fix typo (#284) (Jason Cooke)
    • [62ca523048] - build: use clang-format from npm (Matheus Marchini) #276
    • [6424992013] - src: apply clang-format rules (Matheus Marchini) #276
    • [ecfbdcab0b] - src: move JSDate "ToString" logic to JSDate class (Daniel Beckert) #257
    • [c29d5af61d] - test: disable flaky test for findrefs -s (Matheus Marchini) #244
    • [aad5414756] - src: add recursive option to findrefs command (Daniel Beckert) #244
    • [85f067aad8] - build: add linter scripts and use it on travis (Matheus Marchini) #260
    • [886a03d5c8] - src: run clang-format (Matheus Marchini) #260
    • [64a4e5e31d] - build: install clang-format from npm (Matheus Marchini) #260
    • [ea06ef5ff1] - meta: drop support for lldb 3.8 (Matheus Marchini) #263
    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Feb 22, 2019)

    Notable Changes

    • Teach llnode how to print Symbol properties names

    Commits

    • [fdb49b8] doc: fix typo in README.md (hardfist)
    • [51bf1f6] src: fix formatting of context address within JSFunction (Matheus Marchini)
    • [a36611f] test: move workqueue tests to correct folder (Matheus Marchini)
    • [0c1e3ae] src: make source list -l flag optional (Matheus Marchini)
    • [a295239] src: refactor JSError stringifier (Matheus Marchini)
    • [9f3dce3] build: add coverage for javascript code (Matheus Marchini)
    • [43edf43] build: add support to gcov and codecov (Matheus Marchini)
    • [59b65c4] build: add support for Android Termux build (James R. Gambale, Jr)
    • [e30beba] src: teach llnode how to print Symbol properties names (Matheus Marchini)
    • [388605f] src: fix performance regression (Matheus Marchini)
    • [dbd95d7] build: load lldb symbols at runtime (Dane Springmeyer)
    • [c17d0d1] src: fix build on older compilers (gcc 4.8) (Matheus Marchini)
    • [c851b9a] src: introduce Printer class (Matheus Marchini)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.0(Dec 10, 2018)

    Notable Changes:

    • src: colorize output for findjsinstances
    • src: option to limit output of findjsinstances
    • src: print stack for error objects
      • Works best for Node.js v8.x or later. v6.x has some known issues (see https://github.com/nodejs/llnode/issues/250)
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Sep 25, 2018)

    • src: add node's internals constants
    • build: convert the llnode shortcut to javascript
    • build: add install script
    • build: add Windows support
    • src: move ParseInspectOptions out of CommandBase
    • src: implement JavaScript API
    • doc, test: doc API design, add tests
    • src: add commands to inspect the workqueue
    • src: run make format with clang-format 6.0.1
    • src: check oob before slicing String
    • doc: update build matrix to use travis-ci.com
    • build, doc: drop support for Node.js v9.x
    • build: add names to our Travis builds
    • src: inspect properties with descriptor details
    • src: fix inspection of read-only properties
    • src: fix context inpection for V8 6.8
    • src: inspect context objects (Node.js v10.x+)
    • test: increase Linux test coverate
    • src: run make format on all files
    • src: fix JSError inspection
    • src: show context objects within findrefs
    • package: update description to match GitHub
    Source code(tar.gz)
    Source code(zip)
  • v1.7.1(Jun 6, 2018)

    • src: fix backtrace for V8 6.7
    • travis: increase versions and OS coverage
    • src: fix object inspection for V8 6.4 (#192)
    • test: more consistent test for findjsobjects -d (#188)
    • src: update constants to match V8 6.4 (#186)
    • build: separate lldb_include_dir and lldb_lib_dir (#185)
    Source code(tar.gz)
    Source code(zip)
  • v1.7.0(Mar 31, 2018)

    • build: merge gyp_llnode into scripts/configure.js (#182)
    • findrefs: refactor ::PrintRefs template strings (#178)
    • build: refactor os-specific scripts into different files (#175)
    • test: refactor inspect-test (#176)
    • build: fix make install-*
    • doc: add logo to the README.md
    • doc: add logo to the project
    • scripts: do not check llnode.sh into git (#172)
    • src: do not create global llscan or global llv8
    • test: fix hanging when testing with prepared core
    • src: fix backtrace with v8 6.4 (#168)
    • test: move core saving and loading into common.js (#167)
    • src: add a detailed output to findjsobjects
    Source code(tar.gz)
    Source code(zip)
  • v1.6.3(Jan 15, 2018)

    • release: remove out/ in files of package.json (#164)
    • doc: add section about developing and testing
    • doc: update installation and loading instructions
    • doc: add npm badge and use flat square style
    • test: fix lldb 3.9+ version separator for linux
    • src: load symbols from shared lib
    • test: add d8 scenario fixture
    • src: print more debug info when LLNODE_DEBUG=true
    • src: add note about frame type removal
    • Switch to LLDB 3.9. (#152)
    • test: add containsLine function
    • travis: show debug output in CI
    • test: proper error-first handling
    • test: show lldb output when timing out
    • travis: test node 4, 6, 8, 9 with lldb-3.9
    • src: add total row to findjsobjects command (#148)
    • Update travis badge. (#142)
    • doc: update LLNODE_RANGESFILE documentation (#140)
    • Try to use the version from llvm-config on MacOS (#141)
    Source code(tar.gz)
    Source code(zip)
  • v1.6.2(Sep 12, 2017)

    • Support V8 6.1 postmortem data( #130)
    • Add support for big endian systems (#120)
    • Add findjsinstances --verbose option (#125)
    • Simplify lldb version handling on installation (#134)
    • Fix crash on sliced external strings (#123)
    • Combine array-length and string-length arguments to v8 inspect (#124)
    • Support thin strings and stub frames (#121)
    Source code(tar.gz)
    Source code(zip)
  • v1.6.1(Aug 14, 2017)

    • Improved findrefs execution speed after first use (#114)
    • Freebsd installation via npm install. (#96)
    • Support reading contents from buffers in addition to arrays and strings. (#116)
    Source code(tar.gz)
    Source code(zip)
  • v1.6.0(Jul 7, 2017)

    • Add llnode command (#108)
    • Allow npm install to work in git clone (#110)
    • Fix build error with lldb 3.8 (#109)
    • Print builtins and unnamed stack frames (#104)
    • Implement v8 inspect --array-length for large arrays (#105)
    • Don't crash with no arguments to print (#106)
    • Fix build badge in README.md (#107)
    Source code(tar.gz)
    Source code(zip)
  • v1.5.1(Jun 20, 2017)

  • v1.4.3(Apr 20, 2017)

Owner
Node.js
Node.js
Node is running but you don't know why? why-is-node-running is here to help you.

why-is-node-running Node is running but you don't know why? why-is-node-running is here to help you. Installation Node 8 and above: npm i why-is-node-

Mathias Buus 1.5k Dec 30, 2022
Dynamic tracing for javascript, in javascript (similar dtrace, ktap etc)

jstrace Dynamic tracing for JavaScript, written in JavaScript, providing you insight into your live nodejs applications, at the process, machine, or c

null 387 Oct 28, 2022
API Observability. Trace API calls and Monitor API performance, health and usage statistics in Node.js Microservices.

swagger-stats | API Observability https://swaggerstats.io | Guide Trace API calls and Monitor API performance, health and usage statistics in Node.js

slana.tech 773 Jan 4, 2023
A Node.js tracing and instrumentation utility

njsTrace - Instrumentation and Tracing njstrace lets you easily instrument and trace you code, see all function calls, arguments, return values, as we

Yuval 354 Dec 29, 2022
thetool is a CLI tool to capture different cpu, memory and other profiles for your node app in Chrome DevTools friendly format

thetool thetool is a CLI tool to capture different cpu, memory and other profiles for your node app in Chrome DevTools friendly format. Quick start np

null 200 Oct 28, 2022
Node.js debugger based on Blink Developer Tools

Node Inspector Overview Node Inspector is a debugger interface for Node.js applications that uses the Blink Developer Tools (formerly WebKit Web Inspe

null 12.6k Dec 29, 2022
ndb is an improved debugging experience for Node.js, enabled by Chrome DevTools

ndb ndb is an improved debugging experience for Node.js, enabled by Chrome DevTools Installation Compatibility: ndb requires Node >=8.0.0. It works be

null 10.8k Dec 28, 2022
[OBSOLETE] runs Node.js programs through Chromium DevTools

devtool ⚠️ Update: This tool is mostly obsolete as much of the philosophy has been brought into Node/DevTool core, see here for details. If you wish t

Jam3 3.8k Dec 20, 2022
Debug Node.js code with Chrome Developer Tools.

Debug Node.js code with Chrome Developer Tools on Linux, Windows and OS X. This software aims to make things easier ?? . With ironNode you have the fu

Stephan Ahlf 2.3k Dec 30, 2022
🐛 Memory leak testing for node.

Leakage - Memory Leak Testing for Node Write leakage tests using Mocha or another test runner of your choice. Does not only support spotting and fixin

Andy Wermke 1.6k Dec 28, 2022
Long stack traces for node.js inspired by https://github.com/tlrobinson/long-stack-traces

longjohn Long stack traces for node.js with configurable call trace length Inspiration I wrote this while trying to add long-stack-traces to my server

Matt Insler 815 Dec 23, 2022
Locus is a debugging module for node.js

ʆ Locus Locus is a debugging module which allows you to execute commands at runtime via a REPL. Installing npm install locus --save-dev Using require(

Ali Davut 300 Nov 13, 2022
He is like Batman, but for Node.js stack traces

Stackman Give Stackman an error and he will give an array of stack frames with extremely detailed information for each frame in the stack trace. With

Thomas Watson 242 Jan 1, 2023
Streamline Your Node.js Debugging Workflow with Chromium (Chrome, Edge, More) DevTools.

NiM (Node.js --inspector Manager) Streamlines your development process Google Chrome Web Store (works with any Chromium browsers: Google's Chrome, Mic

Will 188 Dec 28, 2022
A pretty darn cool JavaScript debugger for Brackets

Theseus Theseus is a new type of JavaScript debugger for Node.js, Chrome, and both simultaneously. It is an extension for the Brackets code editor. Th

Adobe Research 1.3k Dec 20, 2022
📡 Encrypt and authenticate DevTools to use it securely remotely. Add HTTPS, and authentication to --remote-debugging-port to debug, inspect and automate from anywhere and collaborate securely on bugs.

?? Encrypt and authenticate DevTools to use it securely remotely. Add HTTPS, and authentication to --remote-debugging-port to debug, inspect and automate from anywhere and collaborate securely on bugs.

Cris 9 May 5, 2022
Well-formatted and improved trace system calls and signals (when the debugger does not help)

ctrace Well-formatted and improved trace system calls and signals (when the debugger does not help). Why? Awesome tools strace and dtruss have only on

Aleksandr Komlev 117 Dec 27, 2022
A project to showcase a poc of distributed systems with message queue, graphql, grpc, http server with added monitoring and tracing capabilities.

trace-sandbox Trace sandbox is a project to showcase a poc of distributed systems with message queue, graphql, grpc, http server with added monitoring

Alfian Pramudita 6 Jun 24, 2021
An enchanced useState hook which keeps track of the states history, allowing you to undo and redo states.

useTimeline An enchanced useState hook which keeps track of the states history, allowing you to undo and redo states. useTimeline is a simple hook bas

null 13 Apr 22, 2022