You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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:raisebadsignal
will observe that it got aSIGPROF
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 functionbadsignalgo
. 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 callsmalloc
.In other words, we've called
malloc
in a signal handler. That is not a good idea in general. In practice, if theSIGPROF
occurred while executing withinmalloc
, 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 callingcgocallback
. No other non-forwarded signal is particularly likely to occur duringmalloc
, so that may be sufficient for 1.7.The text was updated successfully, but these errors were encountered: