runtime/cgo: test signal from foreign thread before cgo call #10268
Comments
|
Does the signal happen in a global ctor? Or in a thread created by a global ctor? |
|
I assume in a foreign thread created by a global ctor. But I'm diagnosing from afar without code. |
crawshaw
changed the title
|
Maybe we want to split notion of extram's and disabled deadlock detection then? E.g. allow to have spare extram's but don't disable deadlock detection? And then create the first extram in schedinit, but disable deadlock detection on the first cgocall. |
|
It seems to me that we should disable deadlock detection if a program has any functions exported by cgo. |
|
static constructor creates threads, and signals are delivered to those
threads.
As those threads don't have g, sigtramp will call badsignal, which uses
cgocallback.
For #10207, I suspect the foreign thread is the one for the task debug
port, so
we should block every signal in that thread and try again without the
original
fix.
Another fix is that in badsignal, if exteram is not available, see if the
signal can
be ignored, if so, just return; otherwise print a message and exit.
|
|
Yes, sigsend does nothing if sig.inuse is false, so one quick way to avoid many problems is for badsignal to do nothing in that case. It's not a real solution, though. |
|
@minux, it all sounds good, except for the very last part. But I am curious whether the rest of what you proposed will fix the original problem or not. |
|
The last part is essentially what will happen today (before the fix to
#10207).
If we want deadlock detection, then we can't start extram until the first
cgo call,
and if we don't have extram, we can't deliver the received signal if it's
received
on the foreign thread. What's more, we can't ignore the signal, because the
user program might be waiting for that signal. The best thing we can do is
to
crash as before ("cgocallback before cgo call").
The best way to fix this is to make badsignal do the signal delivery without
cgocallback.
|
|
We fixed #10139, which I think was important for Go 1.5. I don't believe this one is as important. It can likely wait until Go 1.6, although it's subtle enough it should be done early in the cycle. |
|
Rereading this thread, I'm completely lost. Can someone give a clear statement of the problem? (What did you do? What happened? What did you expect instead?) If not, let's close this bug. |
|
Not to speak for @crawshaw, but I think this issue is really just about adding a test. As far as I can see the current code works. See the lengthy discussion at the end of https://golang.org/cl/7978 . |
gopherbot
added
the
compiler/runtime
A C++ program can trigger the Go signal handler from a global constructor before any cgo calls are made. As badsignal uses cgocallback, this requires an extra M be initialized. This was done for #10207, as it appears to sometimes happen with the os/signal tests on darwin/arm.
It needs a robust test.
There also needs to be some decision made about how this interacts with the deadlock detector. (Perhaps another issue.)
/cc @dvyukov
The text was updated successfully, but these errors were encountered: