-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: signal_amd64x.go:76 SIGINT on darwin/amd64 causes segfault under c-shared library #13034
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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:
|
CL https://golang.org/cl/17903 mentions this issue. |
…dlers Only install signal handlers for synchronous signals that become run-time panics. Set the SA_ONSTACK flag for other signal handlers as needed. Fixes #13028. Update #12465. Update #13034. Update #13042. Change-Id: I28375e70641f60630e10f3c86e24b6e4f8a35cc9 Reviewed-on: https://go-review.googlesource.com/17903 Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
CL https://golang.org/cl/18062 mentions this issue. |
A refinement of the report in #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:
The text was updated successfully, but these errors were encountered: