go: net: DNS broken on darwin without cgo (1.13 regression)
I was testing some new code for the Go build system and found that a simple TCP dial doesn’t work on Mac anymore, at least when the binary is cross-compiled.
Code is just:
var coordDialer = &net.Dialer{
Timeout: 10 * time.Second,
KeepAlive: 15 * time.Second,
}
// dialCoordinatorTCP returns a TCP connection to the coordinator, making
// a CONNECT request to a proxy as a fallback.
func dialCoordinatorTCP(ctx context.Context, addr string) (net.Conn, error) {
tcpConn, err := coordDialer.DialContext(ctx, "tcp", addr)
… with a context.Background() for ctx.
It always times out after 10 seconds.
But if I redeploy the same code but built with Go 1.12.x, it works fine.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 52 (46 by maintainers)
Commits related to this issue
- dashboard: add darwin-amd64-nocgo config, remove nacl-386 trybot Also remove dead nacl-arm. It hasn't run in ages. And update netbsd comment about why 386 doesn't run. And correct its VM image name.... — committed to golang/build by bradfitz 5 years ago
- runtime: use default system stack size, not 64 kB, on non-cgo macOS At least one libc call we make (res_search, which calls _mdns_query and then mdns_item_call) pushes a 64 kB stack frame onto the st... — committed to golang/go by rsc 5 years ago
- net: fix non-cgo macOS resolver code This code was added in April in CL 166297, for #12524. This CL fixes the following problems in the code: - The test for failure in the assembly stubs checked fo... — committed to golang/go by rsc 5 years ago
I thought y’all just wanted me to make the test not hang. Actually passing is a higher bar. Will try. 😃
FYI - you don’t need to comment on an issue to subscribe to it. There is a subscribe button.
@groob, the main thread was running with an 8 MB stack and all other threads were running with 64 kB. The intermittency was based on which stack you got. The 8 MB one would run to completion and return the error; the smaller ones would fault in C due to the stack overflow and then fault again in Go trying to understand the C fault.