Closed glycerine closed 8 years ago
I'm getting sporadic crashes (on linux, fedora22 amd64) on my host R process shutdown. It appears that SIGCHLD is occassionally intercepted by the cshared-library-go runtime. Not sure if this should be addressed along with this ticket or distinct issue. If the fix for this ticket involves allowing the host to avoid guest doing any signal handling at all then the SIGCHLD intercept below would be fixed automatically.
Stack trace from the SIGCHLD interception, is here:
(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)
CL https://golang.org/cl/17903 mentions this issue.
CL https://golang.org/cl/18062 mentions this issue.
A refinement of the report in https://github.com/golang/go/issues/13028 to focus on the OSX-only segfault that happens when I send SIGINT to program that has a c-shared library loaded.
Details: jaten@Jasons-MacBook-Pro:~$ go version # at tip. Also happens in go1.5.1. go version devel +79a3b56 Thu Oct 22 21:19:43 2015 +0000 darwin/amd64
On OSX Yosemite, 10.10.5, darwin amd64.
I built a c-shared library (source code: https://github.com/glycerine/rmq), loaded it under R (a large C program), then called from C into the c-shared go library. Inside the library we start a web-server and the do ListenAndServe(). I have established signal handlers in the go code for SIGINT. However pressing ctrl-c and sending SIGINT to the process results in a segfault on OSX, but not on linux.
Under gdb on osx, I observe that the segfault is isolated to go1.6-dev/src/runtime/signal_amd64x.go:76, the value of c is out of bounds in the line
if c.sigcode() != _SI_USER && flags&_SigPanic != 0 {
.a backtrace from gdb:
The signal handling Go code for SIGINT consisted of either one or two prior calls to signal.Notify().
A full stack dump from pressing ctrl-c generates a seg-fault with this stack trace not under gdb:
another, earlier, example of the same thing: