Build issues on FreeBSD ZoF "unexpected stale targets"

[mat....@gmail.com]

I'm not sure where to ask this since this isn't actually a Go bug. Go 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However, with the ZFS rebased to ZFS on Linux I'm seeing issues that I can only reproduce building Go. I either see:

from one run:
go install encoding/gob: copying /tmp/go-build309923892/b103/_pkg_.a to /testpool/freebsd-ports/lang/go/work/go/pkg/freebsd_amd64/encoding/gob.a: read /tmp/go-build309923892/b103/_pkg_.a: bad address

another:
cmd/pack
cmd/vendor/github.com/google/pprof/internal/elfexec
go install go/types: copying /tmp/go-build100514402/b143/_pkg_.a to /testpool/freebsd-ports/lang/go/work/go/pkg/freebsd_amd64/go/types.a: read /tmp/go-build100514402/b143/_pkg_.a: bad address
cmd/go/internal/cache

And dtrace doesn't show any system call returning EFAULT when this happens. So maybe something in libc? Unclear.

Or from another run:

HASH[build runtime/internal/sys]
HASH[build runtime/internal/sys]: "go1.12.7"
HASH[build runtime/internal/sys]: "compile\n"
HASH[build runtime/internal/sys]: "goos freebsd goarch amd64\n"
HASH[build runtime/internal/sys]: "import \"runtime/internal/sys\"\n"
HASH[build runtime/internal/sys]: "omitdebug false standard true local false prefix \"\"\n"
HASH[build runtime/internal/sys]: "modinfo \"\"\n"
HASH[build runtime/internal/sys]: "compile go1.12.7 [] []\n"
HASH[build runtime/internal/sys]: "GO$GOARCH=\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/arch.go: d9b0b7e72538d421b2607acaba60ca49f20ef584b3d1d191c6729e35fbb8101d
HASH[build runtime/internal/sys]: "file arch.go 2bC35yU41CGyYHrKumDK\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/arch_amd64.go: 1301163254cfb431f101054609fd549f284be1ea42c0bfb3be0ba4b3dddac13d
HASH[build runtime/internal/sys]: "file arch_amd64.go EwEWMlTPtDHxAQVGCf1U\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/intrinsics.go: 8b469a461e1d983706e0b3635715ce70691adc5db7c4e067b88cc59f40cd66f4
HASH[build runtime/internal/sys]: "file intrinsics.go i0aaRh4dmDcG4LNjVxXO\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/stubs.go: 23b3e5c631b086fe7a2dec4bf044600e034bf6a8eeb25e0a19efc4ce6311423d
HASH[build runtime/internal/sys]: "file stubs.go I7PlxjGwhv56LexL8ERg\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/sys.go: 55e021891200a7e6a5c371c8a1ab71b6c15aeb16ea6c1b192185d17df8c8b18f
HASH[build runtime/internal/sys]: "file sys.go VeAhiRIAp-alw3HIoatx\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/zgoarch_amd64.go: 6f2fa4ebe8999a3b7cfe3ead6e24b8356ed842292f23cb1b4f995c0b5b45126b
HASH[build runtime/internal/sys]: "file zgoarch_amd64.go by-k6-iZmjt8_j6tbiS4\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/zgoos_freebsd.go: 89479e2fc5aba8e27f05a11c1b0f2e333c6f203aa502497d7be38aa6b5819493
HASH[build runtime/internal/sys]: "file zgoos_freebsd.go iUeeL8WrqOJ_BaEcGw8u\n"
HASH /testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/zversion.go: 492d4832fcbc095d59151e03f7b144693586a844678f2033fc73928d9093687d
HASH[build runtime/internal/sys]: "file zversion.go SS1IMvy8CV1ZFR4D97FE\n"
HASH[build runtime/internal/sys]: 7c65aacaf2f596f2ec3d978ef53e6ff58dd327a8a91976438813cad31190ee93
HASH subkey 7c65aacaf2f596f2ec3d978ef53e6ff58dd327a8a91976438813cad31190ee93 "stdout" = 75d0847bbde28d271e659eeb7d91770e854c2ed5c3a127b9109c3f001f0df627
runtime/internal/sys true
go tool dist: unexpected stale targets reported by /testpool/freebsd-ports/lang/go/work/go/pkg/tool/freebsd_amd64/go_bootstrap list -gcflags="" -ldflags="" for [cmd/asm cmd/cgo cmd/compile cmd/link runtime/internal/sys]:
        STALE runtime/internal/sys: not installed but available in build cache

and another:
go tool dist: unexpected stale targets reported by /testpool/freebsd-ports/lang/go/work/go/pkg/tool/freebsd_amd64/go_bootstrap list -gcflags="" -ldflags="" for [cmd/asm cmd/cgo cmd/compile cmd/link runtime/internal/sys]:
        STALE cmd/asm: stale dependency: internal/race
        STALE cmd/cgo: stale dependency: internal/race
        STALE cmd/compile: stale dependency: internal/race
        STALE cmd/link: stale dependency: math/bits

*** Error code 2

Could someone tell me what it's doing when the first type of failure occurs and what the STALE error means? I've seen the latter in past issues, but there was no indication of what that was a symptom of.

Thanks.

-M

[B Carr]

What does this part mean? "...with the ZFS rebased to ZFS on Linux..."

[Steven Hartland]

Mat is actually running a non-standard kernel, with the ZFS filesystem from the core OS replaced with a ZFS version derived from Linux ZFS port.

I've not looked at the details of the port, but one suggestion would be do you see the same behaviour if you build on UFS volume while still running the kernel with the ZFS port.

This may indicate if a strange filesystem level issue is causing corruption or if the port has changed / broken a kernel feature go is relying on.

    Regards
    Steve

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%40googlegroups.com.

[mat....@gmail.com]

On Friday, July 19, 2019 at 2:24:30 PM UTC-7, Steven Hartland wrote:

Mat is actually running a non-standard kernel, with the ZFS filesystem from the core OS replaced with a ZFS version derived from Linux ZFS port.

I've not looked at the details of the port, but one suggestion would be do you see the same behaviour if you build on UFS volume while still running the kernel with the ZFS port.

This may indicate if a strange filesystem level issue is causing corruption or if the port has changed / broken a kernel feature go is relying on.

Haven't tried UFS but he problem doesn't occur when using tmpfs for /tmp when using ZoF or when using the ZFS in base for /tmp. Trussing the build slows it down to the point where it succeeds. I attribute this to some sort of race in ZoF but not in "legacy" ZFS. vfsops and vnops are essentially the same as upstream so I'm really not sure what to look for.

-M

 

    Regards
    Steve

On 19/07/2019 22:01, B Carr wrote:

What does this part mean? "...with the ZFS rebased to ZFS on Linux..."

On Friday, July 19, 2019 at 1:37:02 PM UTC-6, mat...@gmail.com wrote:

I'm not sure where to ask this since this isn't actually a Go bug. Go 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However, with the ZFS rebased to ZFS on Linux I'm seeing issues that I can only reproduce building Go.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Steven Hartland]

You might want to see if dtrace can shed some light on this?

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e5b4f8cf-6203-4a93-88fe-b4d61d83b12d%40googlegroups.com.