On: The Reliability of Go

[tezza]

Well Java doesn't generally segfault either... until you start referencing external libraries ( freetype.dll , serial_comms.dll, swt.lib )

I presume Go ( CGO ) will have to deal with segfaults too, and I'd like to understand what it does.

[exch → tezza]

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:

http://play.golang.org/p/uoBKsRIJB7

[tezza → exch]

Thanks exch, that's really decent of you to construct an example.

I wonder that if there are multiple threads / goroutines are their callchains also printed ?

[exch → tezza]

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.

http://play.golang.org/p/GQxdXpWdZD

[4ad → tezza]

As I said, this is a property of the system.

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.

[1] http://man7.org/linux/man-pages/man5/core.5.html