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: SIGPIPE is raised when using net.DialTimeout and timeout is reached #18770

akamensky opened this issue Jan 24, 2017 · 5 comments


None yet
6 participants
Copy link

commented Jan 24, 2017

What version of Go are you using (go version)?

1.7.4 darwin

What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rk/g9b46vzx70g86vhvqtmwtjxw0000gn/T/go-build402316604=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Application that connects to remote server using net.DialTimeout. The application part that connects remotely is written in Go, the application GUI is written in C++ (Qt5). And Go part is statically linked to GUI.

The pseudo-code that causes the issue:

	serverConn, err := net.DialTimeout("tcp", c.remoteServer, CONNECT_TIMEOUT) // 5 seconds timeout
	if err != nil {
		return err // Error is fully handled in calling method

What did you expect to see?

Since error is handled and written to STDERR as a log message I expect to see message and app keep on running.

What did you see instead?

The app exits with code 141 (SIGPIPE). If in C++ part I specify to ignore SIGPIPE (such as signal(SIGPIPE, SIG_IGN);) then I can see log output. Without that the application exists silently**(!)**, which I believe should not be the case, if we raise SIGPIPE, then we at least should see stack trace leading us to the line where EPIPE happened....


I think preferred solution would be not to raise SIGPIPE at all. Since I can get err value on timeout and can handle it appropriately. FYI, net package has no error type for timeout error. so the only way to ensure that the error is due to timeout is to lookup for substring in error message...

@ianlancetaylor ianlancetaylor changed the title SIGPIPE is raised when using net.DialTimeout and timeout is reached runtime: SIGPIPE is raised when using net.DialTimeout and timeout is reached Jan 24, 2017


This comment has been minimized.

Copy link

commented Jan 24, 2017

We need to see a complete example that demonstrates the problem. See for how the Go runtime handles SIGPIPE. What you are describing is not what is intended to happen, and the runtime has code that is intended to ensure that it does not happen. So we need a test case we can run ourselves so that we can find out why it is not working for you.


This comment has been minimized.

Copy link

commented Jan 24, 2017

Also, please try Go 1.8. We're no longer fixing bugs (only security issues) in Go 1.7.


This comment has been minimized.

Copy link

commented Jan 26, 2017

this is probably dup of #17393 isn't it @eliasnaur ?


This comment has been minimized.

Copy link

commented Jan 26, 2017

@dcu Thank you for the reference, looks like the same though slightly different use-case.

I agree with comment in referenced issue that in theory Go should not be raising SIGPIPE at all (instead of ignoring it). SIGPIPE is meant for environment where it is not possible to handle error upon write/read to/from closed socket, which is the case for low level languages. Go already provides necessary tools for managing socket errors.

I guess can close as a dup, though sad to see that (according to referenced issue) the fix for this won't be in 1.8.


This comment has been minimized.

Copy link

commented Jan 26, 2017

It looks like a dup of #17393. I'll try (again) to fix it for Go 1.9.

@eliasnaur eliasnaur closed this Jan 26, 2017

@golang golang locked and limited conversation to collaborators Jan 26, 2018

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.