tjfontaine

MDB is unlike most debuggers you've experienced.

It is not a source level debugger like gdb or lldb or even Node's builtin debugger

Generally used for postmortem analysis.

Postmortem is for Production and Development

We operate mostly on core files, though you can attach to running processes as well.

tjfontaine

$ kubessh node.info/external.ipaddress 192.168.2.2
If you don't see a command prompt, try pressing enter.
[root@k8s-worker-ad1-0 /]# exit

$ kubectl get pods
NAME                     READY     STATUS    RESTARTS   AGE
kubessh-tjfontai-15628   1/1       Running   0          7s

tjfontaine

#!/bin/bash

##  s/^|\s\+\(\w\+\)\s\+|\s\+\(.*\)\s\+|\s\+\(.*\)\s*|/sdc-policy create --name="can \1" --rules="can \1" --description="can \3"/
##  s/^|\s\+\(\w\+\)\s\+|\s\+\(.*\)\s\+|/sdc-policy create --name="can \1" --rules="can \1"/

set -xe

sdc-policy create --name="can putdirectory" --rules="can putdirectory" --description="can create directories, update directory metadata "
sdc-policy create --name="can getdirectory" --rules="can getdirectory" --description="can list contents of directories "
sdc-policy create --name="can deletedirectory" --rules="can deletedirectory" --description="can delete (empty) directories "

tjfontaine

Aug 5, 2013 11:36:00 AM com.kenai.jffi.NativeMethods$ResourceHolder finalize
WARNING: Exception when freeing native method struct array: %s
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f0cd4636ee0, pid=20461, tid=139693247178496
#
# JRE version: 6.0_27-b27
# Java VM: OpenJDK 64-Bit Server VM (20.0-b12 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea6 1.12.3

tjfontaine

'use strict';

var domain = require('domain'),
    http = require('http'),
    querystring = require('querystring'),
    util = require('util');

var irc = require('irc');

var config = require('./config');

tjfontaine

There are four kinds of deferral mechanisms in Node.js:

• setTimeout
• setInterval
• setImmediate
• process.nextTick

setTimeout and setInterval are quite familiar to those used to JavaScript in the browser and their semantics are fairly well understood. They return opaque values that can be passed to their clear counterparts, and have been around forever. setImmediate is a newer construct and its adoption in the browser is not very wide, and nextTick is a creation solely unto Node.js. The latter two are mechanisms to queue a callback in the short future, such that currently executing JavaScript may continue. If you're used to trying to do this pattern in the browser you may be used to using something like setTimeout(fn, 0).

If Node.js actually exposed the idea of a turn of the event loop, you would be expecting the scheduled callback to run at the end of the current loop, or the start of the next -- though from the perspective of your application there isn't really a difference. In

tjfontaine

From 8e3070ad5cc17116e47f71290d86b83aa06e98eb Mon Sep 17 00:00:00 2001
From: Timothy J Fontaine <tj.fontaine@joyent.com>
Date: Tue, 12 Aug 2014 00:20:44 +0000
Subject: [PATCH 2/2] descriptions are also 4 byte aligned

---
 usr/src/lib/libproc/common/Pcore.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/usr/src/lib/libproc/common/Pcore.c b/usr/src/lib/libproc/common/Pcore.c

tjfontaine

* thread #1: tid = 0x0000, 0x00007fff88075866 libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fff88075866 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff911f835c libsystem_pthread.dylib`pthread_kill + 92
    frame #2: 0x00007fff8f9debba libsystem_c.dylib`abort + 125
    frame #3: 0x00007fff8f9a8a5f libsystem_c.dylib`__assert_rtn + 321
    frame #4: 0x000000010013ddef node`uv__close(fd=<unavailable>) + 133 at core.c:422
    frame #5: 0x000000010014397b node`uv__stream_try_select(stream=0x00000001004b4c46, fd=0x00000001004b4cf3) + 165 at stream.c:318
    frame #6: 0x000000010014118b node`uv_pipe_open(handle=0x0000000101c00070, fd=2) + 21 at pipe.c:140
    frame #7: 0x0000000100024887 node`node::PipeWrap::Open(args=<unavailable>) + 91 at pipe_wrap.cc:259
    frame #8: 0x000000010016e160 node`v8::internal::FunctionCallbackArguments::Call(this=0x00007fff5fbfe8f0, f=0x000000010002482c)(v8::FunctionCallbackInfo<v8::Value> const&)) + 160 at arguments.c

tjfontaine

>>> import os,fcntl,struct
>>> fd = os.open('file', os.O_WRONLY|os.O_NOCTTY|os.O_CREAT, 0666)
>>> op = struct.pack('hhllhhl', fcntl.F_WRLCK, 0, 0, 0, 0, 0, 0)
>>> 
>>> fcntl.fcntl(fd, fcntl.F_SETLK, op)

tjfontaine

From 270c2deb84b04b508c9d90f58684ee5bf7b3dbca Mon Sep 17 00:00:00 2001
From: Timothy J Fontaine <tjfontaine@gmail.com>
Date: Thu, 9 Jan 2014 13:33:51 -0800
Subject: [PATCH] src: OnFatalError handler must abort()

We are in an unrecoverable state if v8 throws a FatalError, actually
ask the operating system to dump core in this case.

Fixes #6836
---