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
mlowicki opened this issue
Apr 17, 2025
· 0 comments
Labels
A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`C-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.
[EPIPE]
The socket is shut down for writing, or the socket is connection-mode and is no longer connected. In the latter case, and if the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the calling thread.
So without MSG_NOSIGNAL writing to e.g. closed socket leads to SIGPIPE.
If a SIGPIPE signal is received, the Go program will invoke the special handling described above if the SIGPIPE is received on a Go thread. If the SIGPIPE is received on a non-Go thread the signal will be forwarded to the non-Go handler, if any; if there is none the default system handler will cause the program to terminate.
It means Golang programs using Rust library terminate when underlying Rust library doesn't handle disconnected sockets properly (e.g. keep using closed socket).
Discovered problem with 1.83.0 but code for UnixStream doesn't seem to ever pass MSG_NOSIGNAL (so rather not a regression or so).
Apparently old behaviour from #62569 doesn't help neither as Golang runtime doesn't find non-Go signal handler when Rust lib is being used.
MSG_NOSIGNAL doesn't exist everywhere (e.g. not on macOS) so there we could use SO_NOSIGPIPE on a socket but it seems it's already done inside:
jieyouxu
added
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
A-io
Area: `std::io`, `std::fs`, `std::net` and `std::path`
and removed
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
labels
Apr 18, 2025
mlowicki
added a commit
to mlowicki/rust
that referenced
this issue
Apr 18, 2025
A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`C-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.
UnixDatagram
setsMSG_NOSIGNAL
when sending data (https://doc.rust-lang.org/src/std/os/unix/net/datagram.rs.html#516)UnixStream
doesn't have it.Why it's important?
https://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html:
So without
MSG_NOSIGNAL
writing to e.g. closed socket leads toSIGPIPE
.https://pkg.go.dev/os/signal#hdr-Go_programs_that_use_cgo_or_SWIG
It means Golang programs using Rust library terminate when underlying Rust library doesn't handle disconnected sockets properly (e.g. keep using closed socket).
Discovered problem with 1.83.0 but code for
UnixStream
doesn't seem to ever passMSG_NOSIGNAL
(so rather not a regression or so).Apparently old behaviour from #62569 doesn't help neither as Golang runtime doesn't find non-Go signal handler when Rust lib is being used.
MSG_NOSIGNAL
doesn't exist everywhere (e.g. not on macOS) so there we could useSO_NOSIGPIPE
on a socket but it seems it's already done inside:rust/library/std/src/sys/net/connection/socket/unix.rs
Lines 73 to 112 in 15c4cce
Passing
MSG_NOSIGNAL
is handled for other types:rust/library/std/src/sys/net/connection/socket.rs
Lines 399 to 405 in 1f76d21
rust/library/std/src/sys/net/connection/socket.rs
Line 674 in 1f76d21
rust/library/std/src/os/unix/net/datagram.rs
Line 518 in 1f76d21
For
UnixStream
it's purewrite
on underlying file descriptor:rust/library/std/src/os/unix/net/stream.rs
Line 636 in 1f76d21
rust/library/std/src/sys/net/connection/socket/unix.rs
Line 31 in 1f76d21
rust/library/std/src/sys/fd/unix.rs
Line 326 in 1f76d21
The text was updated successfully, but these errors were encountered: