Handling SIGSEGV with recover?

The signal package states:

> Synchronous signals are signals triggered by errors in program
> execution: SIGBUS, SIGFPE, and SIGSEGV. These are only considered
> synchronous when caused by program execution, not when sent using
> os.Process.Kill or the kill program or some similar mechanism. In
> general, except as discussed below, Go programs will convert a
> synchronous signal into a run-time panic.

However, it seems recover() is not catching this.

Program:

package main

import (
	"fmt"
	"unsafe"

	"log"
)

func seeAnotherDay() {
	defer func() {
		if p := recover(); p != nil {
			err := fmt.Errorf("recover panic: panic call")
			log.Println(err)
			return
		}
	}()
	panic("oops")
}

func notSoMuch() {
	defer func() {
		if p := recover(); p != nil {
			err := fmt.Errorf("recover panic: sigseg")
			log.Println(err)
			return
		}
	}()
	b := make([]byte, 1)
	log.Println("access some memory")
	foo := (*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&b[0])) + uintptr(9999999999999999)))
	fmt.Print(*foo + 1)
}

func main() {
	seeAnotherDay()
	notSoMuch()
}

Output:

2017/04/04 12:13:16 recover panic: panic call
2017/04/04 12:13:16 access some memory
unexpected fault address 0xb01dfacedebac1e
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0xb01dfacedebac1e pc=0x108aa8a]

goroutine 1 [running]:
runtime.throw(0x10b5807, 0x5)
           /usr/local/go/src/runtime/panic.go:596 +0x95 fp=0xc420043ea8 sp=0xc420043e88
runtime.sigpanic()
           /usr/local/go/src/runtime/signal_unix.go:297 +0x28c fp=0xc420043ef8 sp=0xc420043ea8
main.notSoMuch()
           /Users/kbrandt/src/sigseg/main.go:32 +0xca fp=0xc420043f78 sp=0xc420043ef8
main.main()
           /Users/kbrandt/src/sigseg/main.go:37 +0x25 fp=0xc420043f88 sp=0xc420043f78
runtime.main()
           /usr/local/go/src/runtime/proc.go:185 +0x20a fp=0xc420043fe0 sp=0xc420043f88
runtime.goexit()
           /usr/local/go/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc420043fe8 sp=0xc420043fe0
exit status 2

Is there any way I could handle SIGSEGV in a way localized to certain parts of the code?

Yes, you will want to use debug.SetPanicOnFault to convert faults at an unexpected (non-nil) address into panics from which you can recover. From the docs:

> SetPanicOnFault controls the runtime's behavior when a program faults at an unexpected (non-nil) address. Such faults are typically caused by bugs such as runtime memory corruption, so the default response is to crash the program. Programs working with memory-mapped files or unsafe manipulation of memory may cause faults at non-nil addresses in less dramatic situations; SetPanicOnFault allows such programs to request that the runtime trigger only a panic, not a crash. SetPanicOnFault applies only to the current goroutine. It returns the previous setting.

For the localization of the impact, note that SetPanicOnFault is set at the goroutine level, so a single goroutine can deal with known unsafe access.

When you encounter a sigsegv, you're really in an all-bets-are-off situation with regards to the program state. The only generally safe thing to do is to stop everything, and possibly have the system dump your memory to file for debugging, which is what Go does. There isn't really any way to "protect the main runtime" in this situation.

If you have a runtime that is running code that is untrusted or unsafe, you really should isolate it into a separate process instead. And if you are the one running the code received from the users (rather than the users themselves), this process should most definitely be sandboxed.

So my advice is, do either of the following:

1. Let it crash and let the user handle it from there. The user writing code causing a sigsegv in Go normally requires more or less active attempts of shooting in the direction of one's foot, so it should be rare and arguably filed under things they are doing at their own risk anyway.
2. Separate it into a supervisor process and an "untrusted/unsafe" child process, where the supervisor picks up improper exit conditions from the child process and reports them appropriately.