4 ms·
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. Nevert
by 4ad 14y ago
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.
- pcwalton 14y agoI'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 http://golang.org/doc/articles/race_detector.html "memory corruption" http://golang.org/doc/faq#atomic_maps http://golang.org/doc/faq#atomic_maps http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."
- 4ad 14y agoYou 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.
- tezza 14y agoWell 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.
- 4ad 14y agoAs 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 http://man7.org/linux/man-pages/man5/core.5.html
- exch 14y agoAs 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 http://play.golang.org/p/uoBKsRIJB7
- tezza 14y agoThanks 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 14y agoIt 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 http://play.golang.org/p/GQxdXpWdZD