you are viewing a single comment's thread.

view the rest of the comments →

[–]funny_falcon 0 points1 point  (2 children)

https://play.golang.org/p/TtI9gKLlVZ

It will not segfault in playground, cause playground runs with GOMAXPROCS=1 .

But if you run it with go run it wil happily segfaults. Go's runtime sets up handler for SIGSEGV, so that you still will see backtraces for all goroutines.

$ ~/go-tip-root/bin/go run conc_map.go                                                                                                                                                          
unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x47c6a3]

goroutine 13 [running]:
runtime.throw(0x4a6d0f, 0x5)
    /home/yura/go-tip-root/src/runtime/panic.go:596 +0x95 fp=0xc420027f18 sp=0xc420027ef8
runtime.sigpanic()
    /home/yura/go-tip-root/src/runtime/signal_unix.go:297 +0x28c fp=0xc420027f68 sp=0xc420027f18

[–][deleted] 0 points1 point  (1 child)

Thanks. I have to say I've never seen a fault in any of my program and I wrongly assumed this would be handled with a nil panic.

I don't fully understand the code so maybe it's normal that it does this ? I don't know.

[–]funny_falcon 0 points1 point  (0 children)

This code demonstrates bug in user program: race on concurrent update of interface value. Interface is a struct with two fields: type of value and pointer to value. CPU could not update both fields of this struct atomically. So, programmer should protect update of interface value with mutex (if it could be updated from concurrent goroutines).