net: go1.8 beta test failures on solaris with non-global zones #18362
Comments
/cc @mikioh |
Thanks for the report. I'm not sure what's the visibility on isolated routing instances under Solaris container (or zone) framework. Can you show us the output of |
The real problem would be which is the better to fill up the Zone field of {IP,UDP}Addr on Solaris; a name (opaque string) or index (integer literal)? |
OK, here you go. First, here is the global zone with one shared-ip zone: === RUN TestInterfaces Then inside the shared-ip zone: === RUN TestInterfaces And then inside an exclusive-ip zone: === RUN TestInterfaces (A zone is either shared-ip or exclusive-ip, you can't mix types.) |
Thanks for the information.
Sounds nice, we can still use interface names for specifying IPv6 zone under Solaris container/zone. |
CL https://golang.org/cl/34670 mentions this issue. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8beta2 solaris/amd64
(also present in 1.8beta1)
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="solaris"
GOOS="solaris"
GOPATH="/export/home/ptribble/go"
GORACE=""
GOROOT="/export/home/ptribble/ud/go"
GOTOOLDIR="/export/home/ptribble/ud/go/pkg/tool/solaris_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build842624664=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
What did you do?
Attempt to build go1.8beta2 using all.bash
What did you expect to see?
Successful build
What did you see instead?
Build fails due to a test failure:
--- FAIL: TestResolveIPAddr (0.00s)
iprawsock_test.go:62: #18: got &net.IPAddr{IP:net.IP{0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1}, Zone:"lo0"}; want &net.IPAddr{IP:net.IP{0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1}, Zone:"lo0:1"}
--- FAIL: TestResolveTCPAddr (0.00s)
tcpsock_test.go:334: ResolveTCPAddr("tcp6", "[fe80::1%lo0]:1") = [fe80::1%lo0]:1, , want [fe80::1%lo0:1]:1,
--- FAIL: TestResolveUDPAddr (0.00s)
udpsock_test.go:87: #13: got &net.UDPAddr{IP:net.IP{0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1}, Port:1, Zone:"lo0"}; want &net.UDPAddr{IP:net.IP{0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1}, Port:1, Zone:"lo0:1"}
FAIL
FAIL net 2.195s
This appears to be a new test failure in 1.8, the same host system built earlier versions successfully.
The problem appears to be down to a confusion caused by solaris zones, which lead to multiple virtual interfaces. In this case, ifconfig in the global zone reports 2 instances of the loopback interface, lo0 and lo0:1
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
lo0:1: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
zone illumos-build
inet6 ::1/128
If I remove the non-global zone, then the build and tests complete without error, but it may not be possible for all users to do so.
The build and tests succeed in a non-global zone, which only sees its own single instance of the lo interface.
The text was updated successfully, but these errors were encountered: