If I had been at that conference, I would have asked the same question.
Thanks for the data point (Yes, fine for production AFAYCT).
What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness.
Does Go leave just a coredump ?
One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of what the threads are doing at the point of failure.
Go doesn't segfault. If a Go program panics it prints stack traces of all goroutines (including the information which goroutine caused the panic) and then exits.
Go programs don't segfault because Go is a memory safe language (unless you use unsafe). They can segfault in the runtime, but that never happened to me. Nevertheless, what happens when you segfault is a property of the system, not of the language implementation. It will happen whatever happens to C programs that segfault.
Go programs can panic but that doesn't produce a core dump, only a stacktrace.
You are correct, I was presenting a simplified view.
While Go was designed with memory safety in mind, the specification does not guarantee memory safety. With that being said, it also doesn't preclude it (unlike C). For example, the gc implementation without parallelism (not to be confused with concurrency) is memory safe while the gc implementation with parallelism is not. This is the reason why GOMAXPROCS is always 1 in the playground and on the App Engine. There's nothing precluding a paralel implementation from also being memory safe.
As a practical example to 4ad's answer, here is the result of NULL-pointer dereference on the C code on my system (Arch Linux 3.9.2-1-ARCH). It does yield a SEGFAULT:
It seems it doesn't go into a lot of detail as to the call-chain for each running goroutine, but this example may just not be very suitable to properly test it. Either way, here is the same deal with a bunch of running goroutines.
The system can be configured to do anything, don't core dump, core dump but overwrite any previous core dump, core dump in some special directory taking care not to overwrite anything, etc[1]. Of course, a process can ask for special treatment, but Go binaries are no different than default C binaries.
Thanks for the data point (Yes, fine for production AFAYCT).
What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness.
Does Go leave just a coredump ?
One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of what the threads are doing at the point of failure.