Identify users and use cases for post-mortem debugging

[hhellyer]

One of the first actions from the meeting was to identify the users and use cases for post mortem debugging. Raising this issue as somewhere to gather that information.

User	Use case	Description
Node.js application developer	Understanding memory usage	A node developer may want to understand what is consuming memory in their application. They need a way to obtain this information and to analyse it.

[davepacheco]

What about splitting that into at least two pieces for understanding both native and JavaScript memory usage? They're slightly different pathologies (missing deallocation vs. leaked references) and separate tools exist for both.

Here are some additions. I erred on the side of keeping some things separate that we might prefer to combine, but I explain below.

User	Use case	Description
Node.js application developer	Debugging crashes in native code	Understanding fatal failure in native code, including Node core, V8, system libraries, application-specific libraries, and add-ons. This involves examining native frames on the stack, function arguments, global variables, and any other native values. This use-case may include failures that span both native and JavaScript code.
Node.js application developer	Debugging crashes in JavaScript code	Understanding fatal failure (e.g., uncaught exceptions or unhandled "error" events) in JavaScript code. This involves examining JavaScript frames on the stack, function arguments, global variables, closures, timers, and any other JavaScript values. This may include failures that span both native and JavaScript code.
Node.js application developer	Debugging unexpected behavior in native code	Similar to debugging crashes, this covers cases where the program hasn't crashed, but developers may still want to inspect stack frames, arguments, and other native values. Developers may want to inspect their program without interrupting it.
Node.js application developer	Debugging unexpected behavior in JavaScript code	Ditto, but focusing on JavaScript-level state (including closures, timers, and any other JavaScript values).

We may want to combine some of these, but I wanted to keep them separate since some tools are targeted specifically at native code only (e.g., gdb(1)) or JavaScript only (e.g., V8's heap dump tools).

As I think about it more, we may want to split this up further into smaller use cases like "examining a stack trace" or "examining specific heap objects". I say that because there are tools that analyze V8 heap dumps that might be useful for understanding some kinds of unexpected program behavior, but may not present stack traces. In that case, there's a matrix of (crash, unexpected behavior) x (native stack, arbitrary native values, JavaScript stack, arbitrary JavaScript values, closures, timers).

As for the user: I stuck with "Node.js application developer" for all these, but we've had a number of use-cases where OS engineers have wanted to examine Node.js core dumps to understand potential issues in system libraries. I think these use cases also apply to support engineers for companies that provide support for Node applications, and I think all of these use-cases also apply to developers of libraries like libuv. Another use case for support engineers is: given a snapshot of a running program, produce a copy of the source for the entire program (including all JavaScript modules).

If people have feedback about the most useful way of enumerating these use cases, I'd be happy to clean this up (in one direction or another).

[richardlau]

Closing due to inactivity. If this work still needs to be tracked, please open a new issue over in https://github.com/nodejs/diagnostics.