Skip to content
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: SIGPROF mishandled on C thread #15994

Closed
ianlancetaylor opened this issue Jun 7, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@ianlancetaylor
Copy link
Contributor

commented Jun 7, 2016

In a cgo-using program a SIGPROF signal that arrives on a thread started by C code will call the following sequence of functions in the runtime package:

cgoSigtramp
sigtramp
sigtrampgo
sigfwdgo (which will normally return false)
badsignal
cgocallback
badsignalgo
raisebadsignal

raisebadsignal will observe that it got a SIGPROF signal and return, and the whole call stack will unwind having done nothing.

However, the call to cgocallback hides a set of internal calls, that include waiting for a new thread to be available to run the Go function badsignalgo. Waiting for a new thread can in some cases mean starting a new thread. Starting a new thread in a cgo-using program means calling _cgo_thread_start, which calls malloc.

In other words, we've called malloc in a signal handler. That is not a good idea in general. In practice, if the SIGPROF occurred while executing within malloc, as is not unlikely, the best result we can hope for is a program deadlock.

We need to, at the very least, check for SIGPROF before calling cgocallback. No other non-forwarded signal is particularly likely to occur during malloc, so that may be sufficient for 1.7.

@ianlancetaylor ianlancetaylor added this to the Go1.7 milestone Jun 7, 2016

@ianlancetaylor ianlancetaylor self-assigned this Jun 7, 2016

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor Author

commented Jun 7, 2016

More generally, of course, we should not simply ignore these SIGPROF signals that occur in C++ code running on C++ threads. If the program has called runtime.SetCgoTraceback we should record the profiling info like any other.

@gopherbot

This comment has been minimized.

Copy link

commented Jun 8, 2016

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.