Hacker News Reader

Comment by 4ad | Hacker News Reader

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.

View on HN

I've heard conflicting things here. I was under the impression that Go was not memory safe while mutating maps without synchronization.

For example, these articles allude to possible memory corruption:

http://golang.org/doc/articles/race_detector.html "memory corruption"

http://golang.org/doc/faq#atomic_maps

http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."

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.

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.

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

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

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 ?

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

Reply on news.ycombinator.com