panics diagnosed incorrectly in parallel mode

[glyn]

A panic of the form "runtime error: invalid memory address or nil pointer dereference" is displayed by ginkgo running in parallel mode as:

  Test Panicked
  map[]
  /usr/local/go/src/pkg/runtime/panic.c:552

  Full Stack Trace
  <etc.>

The map[] is a red herring.

Compare the diagnostics from the same test suite running serially:

  Test Panicked
  runtime error: invalid memory address or nil pointer dereference
  /usr/local/go/src/pkg/runtime/panic.c:552

  Full Stack Trace
  <etc.>

which is much better.

See this gist for a trivial test suite which panics. To reproduce the bug, place the test suite in a directory named temp, cd in, and issue ginkgo -p.

[glyn]

I instrumented internal/failer/failer.go as follows:

func (f *Failer) Panic(location types.CodeLocation, forwardedPanic interface{}) {
    f.lock.Lock()
    defer f.lock.Unlock()

    if f.state == types.SpecStatePassed {
        f.state = types.SpecStatePanicked
        f.failure = types.SpecFailure{
            Message:        "Test Panicked xxx",
            Location:       location,
            ForwardedPanic: forwardedPanic,
        }
        fmt.Println("ZZZ", f.failure)
    }
}

and saw the following printed in the failing case:

ZZZ {Test Panicked /usr/local/go/src/pkg/runtime/panic.c:552 runtime error: invalid memory address or nil pointer dereference 0 0 :0}

which shows the correct panic value is being captured by failer.go.

[onsi]

Brilliant! Thanks for the detailed reproduction steps. We've seen this here and there for a while but never put 2 and 2 together and realized it was an issue only when running in parallel.

Turns out this is a weirdness with how Go was JSON encoding/decoding the forwardedPanic (type interface{}). I've turned it into a string and all is well now.