Skip to main content
100%

Gist 58d08353ae4a8a72f84a

✓ Published0🌍 Public
Aalessioalex
Last edited Sep 11, 2013
Created on Jun 1, 2015

This example demonstrates a debugging technique for retrieving a JavaScript stack trace from a Node.js process stuck in an infinite loop. It shows the step-by-step process of attaching GDB to the running process, setting a breakpoint at `v8::internal::Runtime_StackGuard`, and triggering `v8::V8::TerminateExecution` to reach a safe point where V8 can print the trace via `V8_Fatal`. The output reveals the JavaScript call stack, including function names and file locations.

AI-generated description

Similar vizzes

Loading thumbnail…

Gist 290748

This visualization renders a GDB backtrace as a visual tree of stack frames, showing the execution path at the time of a crash. The data comes from a debugger output (gistfile1.txt) and is plotted as a branching structure where each frame is a node. The visualization encodes the call stack depth and relationships between function calls, with v8 internal functions and addresses labeled. It highlights the sequence of calls from the initial node::Connection::ReadyStateGetter through various V8 internals, using position and links to convey the stack hierarchy and execution flow.

XXXX
76% match
Loading thumbnail…

Gist 203736

This gist contains a raw Ruby backtrace from libruby18.so, showing 72 stack frames of a crashing Ruby 1.8 process. The visualization would likely be a stack trace explorer: a scrolling or hierarchical representation of the call stack, with each frame color-coded or grouped by function (e.g., rb_eval, rb_call, rb_yield) to highlight the execution flow, recursion patterns, and the sequence of calls that led to the error. The data is purely textual, so the visualization would parse and display the backtrace as an interactive structure, letting users inspect the progression of function calls and identify repeated patterns or potential bottlenecks in the interpreter's execution path.

XXXX
64% match
Loading thumbnail…

neat-stack.js

This example shows a function that cleans and colorizes JavaScript stack traces, dimming non-useful log lines to make errors easier to read. It uses the `clean-stack` library to remove noise, then applies a regular expression to identify internal frames from `node_modules`, timers, promises, and webpack imports. Stack lines are split, with the title kept intact and remaining lines passed through a `R.pipe` from Ramda to map each line, using `chalk.dim` for ignored lines and `colorize` for others. The rendered output is a single string combining the title and processed lines, with a special check for “From previous event” lines.

RRestuta
62% match
Loading thumbnail…

Gist 32e4ba8d51a4da505005

This example shows a stack trace from a Python Django application, rendered as a visual tree or graph. It displays the call chain leading to an error, with each function call represented as a node and the relationships between calls shown as edges. The visualization uses `d3.forceSimulation` to position the nodes and links, likely with `d3.select` and SVG elements for rendering. The data originates from the traceback text, parsed to extract file paths, line numbers, and function names. The graph highlights the nested structure of the error, from the top-level module through model definitions to the final lambda function.

Aandybak
61% match
Loading thumbnail…

Gist 3745f53a79313afd139b4eb0a4e97bd2

This example visualizes the nested execution of JavaScript closures by tracing function calls and their returned values. It shows how `makeASum(a)` returns an inner function `sum(b)` that captures the outer variable `a`, and how different instances like `sumOne` and `sumTen` preserve distinct contexts. The rendering uses a custom SVG-based trace, likely driven by D3’s `d3.forceSimulation` for layout and `d3.select` for DOM updates, with console logs mapping to animated nodes and edges. The data originates from the inline script’s execution sequence, displaying call stacks and computed sums in real time.

MMistyBlunch
61% match
Loading thumbnail…

Gist 207932

This example visualizes a recursive stack overflow error from a Ruby application using DataMapper and Merb. The file displays a long, repetitive backtrace where methods such as `dirty_parents?`, `save_parents`, and `any?` endlessly call each other, causing the system to fail. The visualization likely highlights the looping pattern of the error stack, emphasizing the cycle between the controller and the DataMapper resource internals. It serves as a debugging aid to trace the infinite recursion that leads to the "stack level too deep" exception.

XXXX
61% match
Loading thumbnail…

Gist c7d6ce69974576c130ef

This example converts Node.js V8 log files into symbolicated perf maps for generating flame graphs. The `convert.js` script parses code-creation events from the v8 log, extracting the instruction start address, length, type, and function name to produce entries in the format expected by Linux perf. The workflow uses `fs.readFileSync` and `split` to process the log, then pipes the output to a perf map file. The resulting visualization shows CPU sampling data from `perf record` as a flame graph, enabling performance analysis without upgrading Node.js.

Aalessioalex
60% match
Loading thumbnail…

Stack level too deep

This visualization shows a terminal session where a Ruby on Rails test suite fails with a "stack level too deep" SystemStackError, rendering the command output as a plain-text log. The example captures the raw terminal text from a `rake spec:models --trace` run, displaying the rspec test failures and the backtrace pointing to the mongomapper `keys.rb` library. The code uses the standard Ruby runtime and rspec-core, with the output presented literally as the session’s text, reflecting the error’s recursive nature through repeated stack overflow messages. The data source is the command’s stderr and stdout, shown without additional styling or abstraction.

CCaged
60% match