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

1.7.4 darwin

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH=""
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
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"
CXX="clang++"
CGO_ENABLED="1"

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....

Comment

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...