runtime: SIGPIPE from non-main threads not caught by Go on macOS/iOS #33384
Comments
|
The only two options I see are 1) as you suggest, never forward |
|
Change https://golang.org/cl/188297 mentions this issue: |
|
I think we should update the test so that it is not sensitive to this idiosyncrasy, and perhaps update the documentation if we currently make any particular claims about Beyond that, are there any other interactions we should consider? (Did you observe symptoms other than just the test failure?) |
bcmills
added
NeedsInvestigation
|
Note that the currrent test is not failing as far as I know. The question is what to do on macOS if the Go signal handler sees a |
|
The current test does not fail because it runs on the main thread. I discovered the non-main thread case as a rare crash in an iOS app put in the background and then resumed. IOS suspends apps in the background and ongoing network connections time out and are closed. |
|
I would expect the Go signal handler to forward Do we know which fields of the |
|
I would expect the Go signal handler to forward SIGPIPE based on the
program counter that generated the signal rather than the thread that
signal was delivered to.
Do we know which fields of the siginfo_t are populated for SIGPIPE on
MacOS? (Is it possible that they include some indication of the signal's
origin, such as an si_pid or si_fd field?)
There is no si_fd on macOS. According to my tests the si_pid field contains
the process PID, not a thread ID. si_addr didn't seem populated with
anything useful either.
|
|
Change https://golang.org/cl/191785 mentions this issue: |
|
Change was reverted. |
macOS and iOS deliver SIGPIPE signals to the main thread and not the thread that raised it by writing to a closed socket or pipe. SIGPIPE signals can be suppressed for sockets with the SO_NOSIGPIPE option, but there is no similar option for pipes. We have no other choice but to never forward SIGPIPE on macOS. Fixes golang#33384 Change-Id: Ice3de75b121f00006ee11c26d560e619536460be Reviewed-on: https://go-review.googlesource.com/c/go/+/188297 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
macOS and iOS deliver SIGPIPE signals to the main thread and not the thread that raised it by writing to a closed socket or pipe. SIGPIPE signals can be suppressed for sockets with the SO_NOSIGPIPE option, but there is no similar option for pipes. We have no other choice but to never forward SIGPIPE on macOS. This is a fixup of reverted CL 188297. Fixes golang#33384 Change-Id: I09b258b078857ad3b22025bc2902d1b12d2afd92 Reviewed-on: https://go-review.googlesource.com/c/go/+/191785 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
macOS and iOS deliver SIGPIPE signals to the main thread and not the thread that raised it by writing to a closed socket or pipe. SIGPIPE signals can be suppressed for sockets with the SO_NOSIGPIPE option, but there is no similar option for pipes. We have no other choice but to never forward SIGPIPE on macOS. Fixes golang#33384 Change-Id: Ice3de75b121f00006ee11c26d560e619536460be Reviewed-on: https://go-review.googlesource.com/c/go/+/188297 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
macOS and iOS deliver SIGPIPE signals to the main thread and not the thread that raised it by writing to a closed socket or pipe. SIGPIPE signals can be suppressed for sockets with the SO_NOSIGPIPE option, but there is no similar option for pipes. We have no other choice but to never forward SIGPIPE on macOS. This is a fixup of reverted CL 188297. Fixes golang#33384 Change-Id: I09b258b078857ad3b22025bc2902d1b12d2afd92 Reviewed-on: https://go-review.googlesource.com/c/go/+/191785 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Patched in https://golang.org/cl/188297 and ran
What did you expect to see?
No error.
What did you see instead?
Unexpected SIGPIPE from ProvokeSIGPIPE called on a non-main thread.
ProvokeSIGPIPE raises a SIGPIPE from a write to a closed pipe. It is a Go function so the Go runtime should catch it. Alas, it doesn't and the reason appears to be that the signal is raised on the main thread regardless of the raising thread.
To prove my claim, here is a backtrace from running the modified libgo3 test in lldb:
From the backtraces it is clear that the main thread received the SIGPIPE while thread #3 called ProvokeSIGPIPE.
CC @ianlancetaylor: I don't know what to do here. There is SO_NOSIGPIPE but that's only for sockets, not pipes. Should we never forward SIGPIPEs on darwin?
The text was updated successfully, but these errors were encountered: