cmd/cgo, runtime/cgo: misc/cgo/testsovar fails on netbsd

[mikioh]

See http://build.golang.org/log/c35e11fe9fbe842fc43b4299a38560742cc7df69.

##### ../misc/cgo/testsovar
panic: testExportedVar: got "", but want "Hello world"

goroutine 1 [running]:
_/tmp/gobuilder/netbsd-386-minux-91ba0abef12d/go/misc/cgo/testsovar.Test()
    /tmp/gobuilder/netbsd-386-minux-91ba0abef12d/go/misc/cgo/testsovar/cgoso.go:37 +0x384
main.main()
    /tmp/gobuilder/netbsd-386-minux-91ba0abef12d/go/misc/cgo/testsovar/main.go:12 +0x11

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /tmp/gobuilder/netbsd-386-minux-91ba0abef12d/go/src/runtime/asm_386.s:1662 +0x1
2015/07/10 03:44:43 Failed: exit status 2

[alexbrainman]

I think this is broken for a particular netbsd version. I run trybot before submitting https://go-review.googlesource.com/#/c/11119/ and netbsd builder did not complain. It easy to disable this test on netbsd, but maybe this should be investigated first.

Alex

[mikioh]

My dumb guess is that parallelism in cmd/dist and/or the package testing on node under the test with small memory might be the trigger for this sort of issues. I just launched netbsd-386 with 2 cores+1Gig memory, run all.bash a few times, and got the following constantly:

% dmesg | tail -n 3
acpibat0: normal capacity on 'charge state'
UVM: pid 5776 (compile), uid 5963 killed: out of swap
UVM: pid 5585 (link), uid 5963 killed: out of swap

[alexbrainman]

I don't think so. I suspect it is too do with OS tools - GCC or libc or whatever else. I suspect this builder was always broken. I don't think this builder is maintained by Brad and Andrew.

Alex

[mikioh]

Yup, with 2Gig memory, there's no crash of compile/link commands. But misc/cgo/testsovar still fails.

[ianlancetaylor]

CC @minux since it seems to be his builder. This will need to be investigated by somebody who can recreate the problem.

[bradfitz]

We have no netbsd trybots.

[gopherbot]

CL https://golang.org/cl/12060 mentions this issue.

[ianlancetaylor]

Moving to unplanned. Will have to wait for developer using NetBSD.

[ianlancetaylor]

May be fixed by https://golang.org/cl/12470.

[ikrabbe]

I had the same error message, so likely I have the same error. I will check my tool chain. But anyway the extern flag does not hurt.

[alexbrainman]

@ikrabbe we skip misc/cgo/testsovar test on netbsd (search for 11654 in cmd/dist/test.go). If you have netbsd machine, please remove the "skip" and see if build succeeds. If it succeeds, please send another CL with the change. Thank you.

Alex

[ikrabbe]

@alexbrainman No sorry I use a gentoo linux and I currently try to find the compiler commands that where involved in the failed test, that I can exactly reproduce what happened. Currently I miss the linker step for the libcgotest.so with go test -x -v main.go.

[alexbrainman]

You can execute misc/cgo/testsovar test by running:

go tool dist test -no-rebuild -run testsovar

Alex

[ikrabbe]

but this does not say anything about the executed commands. How can I rebuild the dist tool command, without rebuilding the whole set?

[alexbrainman]

cmd/dist is just a Go command, so all normal build commands applicable: 'go build' and 'go install'. For example:

# cd $GOROOT/src/cmd/dist
# go build -o alex
# ./alex test -no-rebuild -run testsovar

##### ../misc/cgo/testsovar

ALL TESTS PASSED (some were excluded)
#

Alex

[ikrabbe]

@alexbrainman Ah, thank you: I changed the dist tester to be more verbose
https://go-review.googlesource.com/12510 cmd/dist/test.go: add command output for dist tests

With this I get

 ~/install/go/misc/cgo/testsovar $ go tool dist test -v -v -no-rebuild testsovar

##### ../misc/cgo/testsovar
# go tool dist test -run=^testsovar$
gcc -fPIC -m64 -pthread -fmessage-length=0 -shared -o libcgosotest.so cgoso_c.c
go build -o main.exe main.go
./main.exe

ALL TESTS PASSED (some were excluded)
rm -rf /tmp/go-tool-dist-255215708

Now we can analyze why or where we need an extern keyword.

[gopherbot]

CL https://golang.org/cl/12510 mentions this issue.

[gopherbot]

CL https://golang.org/cl/12702 mentions this issue.

[ianlancetaylor]

As far as I can tell, this is fixed.