runtime: signal handling: c-shared libraries intercepts SIGCHLD and crashes

[glycerine]

Rather than leave this as a comment on #13034, I'm opening a separate ticket. Conceptually this seems to be or may be distinct concern. The fix for 13034 may fix this as well. Feel free to consolidate depending on determination of the root cause and fix.

The problem details: go1.5.1, on linux amd64/fedora22.

I have a host C program that loads a c-shared Go library. By default, the go runtime embedded in the c-shared library takes over signal handling for most signals, here the issue was with SIGCHLD. At random trials (e.g. 1 out of 10 trials), during a shutdown of the host process, a SIGCHLD would be received by the Go runtime instead and it would then crash the program instead of getting a clean shutdown.

stack trace read from the core dump:

(gdb) bt
#0  runtime.sigaltstack () at /home/jaten/pkg/go1.5.1/src/runtime/sys_linux_amd64.s:355
#1  0x00007ffff14dfc00 in runtime.signalstack (s=0xc820000300)
    at /home/jaten/pkg/go1.5.1/src/runtime/os1_linux.go:337
#2  0x00007ffff14df5d5 in runtime.minit () at /home/jaten/pkg/go1.5.1/src/runtime/os1_linux.go:216
#3  0x00007ffff14e7768 in runtime.needm (x=0 '\000')
    at /home/jaten/pkg/go1.5.1/src/runtime/proc1.go:968
#4  0x00007ffff1513696 in runtime.cgocallback_gofunc ()
    at /home/jaten/pkg/go1.5.1/src/runtime/asm_amd64.s:742
#5  0x00007ffff15135ca in runtime.cgocallback () at /home/jaten/pkg/go1.5.1/src/runtime/asm_amd64.s:714
#6  0x00007ffff14f719b in runtime.badsignal (sig=17)
    at /home/jaten/pkg/go1.5.1/src/runtime/sigqueue.go:169
#7  0x00007ffff14f6212 in runtime.sigtrampgo (sig=17, info=0x672f70, ctx=0x672e40)
    at /home/jaten/pkg/go1.5.1/src/runtime/signal_linux.go:90
#8  0x00007ffff151537b in runtime.sigtramp ()
    at /home/jaten/pkg/go1.5.1/src/runtime/sys_linux_amd64.s:234
#9  0x00007ffff1515380 in runtime.sigtramp ()
    at /home/jaten/pkg/go1.5.1/src/runtime/sys_linux_amd64.s:235
#10 0x0000000000000001 in ?? ()
#11 0x0000000000000000 in ?? ()
(gdb)

I worked around this by elaborately noting all signal handlers, waiting for the go runtime to initialize, and then restoring all original handlers so that the go runtime never gets any signals when it is inside a c-shared library.

Above and beyond fixing the crash, a note on a nice to have: It would be nice to have a simple means of telling the Go runtime -- when embedded in a library -- to not bother to do any signal handling during startup. I have to image this will be a common need when embedding go in libraries.

[gopherbot]

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

[gopherbot]

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