/CC @ianlancetaylor

The runtime never throws SIGSYS but instead notifies it to the user program on some platforms. It's a easy way to make a simple syscall fallback mechanism; try an old system call when a newer system call fails. At least the net package depends on the behavior, perhaps the os package too.

It looks like right now we crash with a stack trace for SIGSYS on Darwin, DragonFly, NetBSD, OpenBSD, and Solaris. We do not crash on FreeBSD and GNU/Linux. As far as I can tell, the different behaviour on GNU/Linux was accidentally introduced in https://golang.org/cl/3749041 .

I think we should undo that change, and make SIGSYS crash with a stack trace on all platforms. The net package does not depend on any particular SIGSYS behaviour. It depends on an invalid system call returning ENOSYS, which it will regardless of how SIGSYS is handled. There are very few cases in which the Linux kernel will send a SIGSYS signal.

It depends on an invalid system call returning ENOSYS, which it will regardless of how SIGSYS is handled.

Thanks for the correction, ENOSYS or EINVAL though.

There are very few cases in which the Linux kernel will send a SIGSYS signal.

Do you have any good idea for fixing FreeBSD? I guess that vanilla FreeBSD kernels throw SIGSYS when they face unknown system calls by default. Are you in favor of introducing FreeBSD kernel version identification? (Or dropping support for FreeBSD 9 and below?)

I don't know enough about FreeBSD. I gather that on FreeBSD if you call an unimplemented system call it sends a SIGSYS signal? What happens if SIGSYS is blocked or ignored?

In any case I'm fine with checking kernel versions on FreeBSD if appropriate. Or, according to https://github.com/golang/go/wiki/FreeBSD we currently don't support anything before FreeBSD 8; it would probably be OK to not support anything before FreeBSD 9.

Patch for this issue here: https://go-review.googlesource.com/#/c/22202/ Comments/thoughts/etc welcome!

CL https://golang.org/cl/22202 mentions this issue.

When we set SIGSYS to _SigThrow + _SigUnblock in runtime/signal_freebsd.go, the following snippet crashes.

package main

import (
        "os/signal"
        "syscall"
)

func main() {
        signal.Ignore(syscall.SIGSYS)
        if _, _, errno := syscall.Syscall6(5682, 0, 0, 0, 0, 0, 0); errno != 0 {
                println(error(errno).Error())
        }
}

# go run syscall.go
SIGSYS: bad system call
PC=0x44e17a m=0

goroutine 1 [syscall]:
syscall.Syscall6(0x1632, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x443b90, 0x0, 0x0)
    /go/src/syscall/asm_freebsd_amd64.s:44 +0x5 fp=0xc820035ec0 sp=0xc820035eb8
main.main()
    /syscall.go:10 +0xe4 fp=0xc820035f50 sp=0xc820035ec0
runtime.main()
    /go/src/runtime/proc.go:188 +0x20a fp=0xc820035fa0 sp=0xc820035f50
runtime.goexit()
    /home/mikioh/go/src/runtime/asm_amd64.s:2054 +0x1 fp=0xc820035fa8 sp=0xc820035fa0

goroutine 5 [runnable]:
os/signal.loop()
    /go/src/os/signal/signal_unix.go:20
created by os/signal.init.1
    /go/src/os/signal/signal_unix.go:28 +0x37
(snip)

See https://github.com/freebsd/freebsd/blob/master/sys/kern/kern_sig.c#L3440.

It sounds like SIGSYS is handled as we expect on every system other than FreeBSD, and on FreeBSD there is nothing we can reasonably do. Seems to me we should just close this issue at this point.

CL https://golang.org/cl/22537 mentions this issue.

Per Ian's last comment, seems like we're done.