/cc @alexbrainman

Interesting. I wonder if we shouldn't be calling in to user code to format the panic message after freezing the world. Presumably on any platform, if an Error method calls cgo or does something nontrivial with goroutines or something, it would deadlock the system in the same way.

We could format all of the panic messages first, then freeze the world, then print them.

This also means we're calling in to user code while holding a runtime lock (paniclk). For example, the following results in a "panic: fatal error: schedule: holding locks", which should not be triggerable by user code:

package main

import "runtime"

type e struct{}

func (e) Error() string {
    runtime.Gosched()
    return "error"
}

func main() {
    panic(e{})
}

This one deadlocks on Linux (I haven't looked in to why the Println is necessary):

package main

/*
char *geterror() {
    return "error";
}
*/
import "C"
import "fmt"

type e struct{}

func (e) Error() string {
    fmt.Println("Hi!")
    return C.GoString(C.geterror())
}

func main() {
    panic(e{})
}

And this one panics with another internal error, "fatal error: stopm holding locks":

package main

import "fmt"

type e struct{}

func (e) Error() string {
    fmt.Println("Hi!")
    fmt.Println("Bye!")
    return "x"
}

func main() {
    panic(e{})
}

These both work in 1.4.3, but not 1.5.

CL https://golang.org/cl/19792 mentions this issue.