davepacheco

void example()
{
    A *a;
    B *b = NULL;

    a = a_new();

    if (! a){
        goto end;
    }

davepacheco

/*
 * testspawn.js: exercises surprising interaction between Node.js "spawn" and
 * bash.  To use this:
 *
 * (1) Create a file in the same directory called "foo.rc", with just one line:
 *
 *     echo "loaded foo.rc"
 *
 * (2) Run this program as:
 *

davepacheco

dap@sharptooth $ cat foo.sh 
#!/bin/bash

cat <<EOF > bar
hello \$(date)
EOF
dap@sharptooth $ ./foo.sh 
dap@sharptooth $ cat bar
hello $(date)

davepacheco

$ uname -v
joyent_20150428T081540Z

$ node -v
v0.10.40

$ file $(which node)
/home/dap/node-v0.10.40-sunos-x64/bin/node:     ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped

$ node

davepacheco

/*
 * Demo: a JavaScript constructor function, even when invoked with "new", can
 * return a completely different object, even one from a completely different
 * class.
 */

var counter = 0;
var lastMyClass;

function MyClass()

davepacheco

/*
 * test-stream.js: demonstrates a case where a Node stream can see an 'error'
 * event after an 'end' event.  This example creates a server socket and then
 * establishes a connection to it.  If the client destroys the socket and the
 * server keeps writing to it, it's possible for the server to see both an 'end'
 * event and an 'error' event.
 */

var mod_net = require('net');
var mod_os = require('os');

davepacheco

This gist contains a test program and sample output that shows a case where a Node Socket can emit an "end" event after an "error" event.

Expected behavior: socket does not emit 'end' event after 'error' event.

Unexpected behavior: socket emits 'end' event after 'error' event.

Works as expected (v0.10):

• illumos: v0.10.43 (both 32-bit and 64-bit): expected behavior

davepacheco

# I've got a shell for testing:
testshell $ echo $$
2133

# From a second shell, I'll instrument every instruction, function entry,
# and function return in the first shell, which is about 142,000 probes:
tracer $ dtrace -ln 'pid2133:a.out::' | wc -l
  142008
tracer $ dtrace -n 'pid2133:a.out::{ @ = count(); }' 
dtrace: description 'pid2133:a.out::' matched 142007 probes

davepacheco

dap@blinky manta-mreq $ rustc -g test.rs 
dap@blinky manta-mreq $ RUST_BACKTRACE=1 ./test
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58

davepacheco

• Top level item

  • second level item

    • third level item