-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
runtime: signal handler interferes with pthread_cancel/join on linux #6997
Labels
Comments
Ah sorry, I must have not rebuilt the runtime package correctly. The binary that blocks in _disable_asynccancel() is still calling rt_sigaction() to register go's signal handler for SIGRTMIN. So I don't understand the cause of the different behaviour (strace reports the thread just keeps trying to call futex() which fails with EAGAIN). I have now properly rebuilt/installed runtime after clearing signal 32's flags, and pthread_cancel works as expected. Similar to issue #3871, but this signal doesn't need to be propagated to all threads at least. NPTL pthreads only mentions the first two realtime signals as reserved so hopefully that's the end of it! |
Sorry if I was unclear - there is still an issue. Using cgo to call into a library that ends up calling pthread_cancel makes the go runtime exit immediately. The fix, however, should be as simple as clearing signal 32's flags in pkg/runtime/signals_linux.h, which causes the runtime to leave pthreads' signal 32 handler in place. |
Thanks - is a diff sufficient? Attachments:
|
I'm sorry, we cannot accept diffs via issues. Please review the contributoin guidelines here http://golang.org/doc/contribute.html. |
This issue was closed by revision c4770b9. Status changed to Fixed. |
CL https://golang.org/cl/170850043 mentions this issue. |
aclements
added a commit
that referenced
this issue
Dec 23, 2014
These signals are used by glibc to broadcast setuid/setgid to all threads and to send pthread cancellations. Unlike other signals, the Go runtime does not intercept these because they must invoke the libc handlers (see issues #3871 and #6997). However, because 1) these signals may be issued asynchronously by a thread running C code to another thread running Go code and 2) glibc does not set SA_ONSTACK for its handlers, glibc's signal handler may be run on a Go stack. Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so this may overflow the Go stack and corrupt heap (or other stack) data. Fix this by ensuring that these signal handlers have the SA_ONSTACK flag (but not otherwise taking over the handler). This has been a problem since Go 1.1, but it's likely that people haven't encountered it because it only affects setuid/setgid and pthread_cancel. Fixes #9600. Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300 Reviewed-on: https://go-review.googlesource.com/1887 Reviewed-by: Ian Lance Taylor <iant@golang.org>
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by sqweek:
The text was updated successfully, but these errors were encountered: