runtime: gdb tests hang on go1.8beta2 gentoo ebuild

[williamh]

Please answer these questions before submitting your issue. Thanks!

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

go1.8beta2 Linux/amd64

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

linux/amd64

What did you do?

I attempted to install go1.8beta2 using our package manager and an ebuild I'm about to add to Gentoo. Testss are turned on which causes the package manager to attempt to run the Go test suite.

What did you expect to see?

A successful installation of Go with all tests passing.

What did you see instead?

The tests failed which aborts installation.

The build log is attached. Any guidance you can provide for troubleshooting this will be greatly appreciated. :-)

build-log.txt

[davecheney]

Can you try building Go outside portage and confirming that the build passes or fails without portarge in the mix?

…

On Wed, Dec 28, 2016 at 2:33 PM, William ***@***.***> wrote: Please answer these questions before submitting your issue. Thanks! What version of Go are you using (go version)? go1.8beta2 Linux/amd64 What operating system and processor architecture are you using (go env)? linux/amd64 What did you do? I attempted to install go1.8beta2 using our package manager and an ebuild I'm about to add to Gentoo. Testss are turned on which causes the package manager to attempt to run the Go test suite. What did you expect to see? A successful installation of Go with all tests passing. What did you see instead? The tests failed which aborts installation. The build log is attached. Any guidance you can provide for troubleshooting this will be greatly appreciated. :-) build-log.txt <https://github.com/golang/go/files/674988/build-log.txt> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18442>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA-6kKVonfG0rltdXuLq7ttgnAJHGks5rMdhxgaJpZM4LWplO> .

[bradfitz]

Looks like your host is just slower than the tests assume.

Try setting GO_TEST_TIMEOUT_SCALE=2 or GO_TEST_TIMEOUT_SCALE=3 in your environment.

But really, the Gentoo package manager should probably just run make.bash instead of all.bash. The tests are mostly interesting for us and others working on Go itself.

[davecheney]

I agree that portage shouldn't run the tests, but with that said I don't think this is a timeout % go test -short net/http os reflect runtime ok net/http 2.893s ok os 0.227s ok reflect 0.053s ok runtime 11.374s ^ my machine. Which is 3x faster than this sample. I'd expect the runtime tests to finish on the sample machine in < 40 seconds.

…

On Wed, Dec 28, 2016 at 2:40 PM, Brad Fitzpatrick ***@***.***> wrote: Looks like your host is just slower than the tests assume. Try setting GO_TEST_TIMEOUT_SCALE=2 or GO_TEST_TIMEOUT_SCALE=3 in your environment. But really, the Gentoo package manager should probably just run make.bash instead of all.bash. The tests are mostly interesting for us and others working on Go itself. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18442 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA5ZnK708TbaYC22dLCOPCsO73AFEks5rMdo2gaJpZM4LWplO> .

[williamh]

Portage does not run the tests unless a user requests that it do so.
We run make.bash to build Go, then optionally "run.bash --no-rebuild" to run the tests.

I can make portage block users from running the tests if they pass outside portage, but I thought we should give the option to run them since your build automatically runs them. :-)

I will run a quick build outside of portage and let you know how it goes.

[williamh]

Hi all,

the tests pass if the build is run without portage in the mix.

If you want, I am willing to attempt to help troubleshoot. Otherwise, I can just block the tests so that portage does not run them.

Which do you prefer?

[williamh]

Hi all,

I ran the build including tests inside portage again, setting GO_TEST_TIMEOUT_SCALE=3 in the environment as suggested.

It failed again, the log is attached.

build-log1.txt

The one thing I can think of is, do the tests write files somewhere on the filesystem? If they do, where? is that path programmable in some way?

[davecheney]

They write to /tmp. You can overwrite it with TMPDIR

…

On Wed, 28 Dec 2016, 16:29 William ***@***.***> wrote: Hi all, I ran the build including tests inside portage again, setting GO_TEST_TIMEOUT_SCALE=3 in the environment as suggested. It failed again, the log is attached. build-log1.txt <https://github.com/golang/go/files/675080/build-log1.txt> The one thing I can think of is, do the tests write files somewhere on the filesystem? If they do, where? is that path programmable in some way? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18442 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA8oWIvNqLTNb3hviowwNDLlsKRSzks5rMfOxgaJpZM4LWplO> .

[williamh]

I pointed TMPDIR to the appropriate location and still got a failure.
The log is attached.
It definitely looks like some kind of timeout, but I'm not sure what is causing it.

build-log2.txt

[davecheney]

I don't think increasing the timeout further will help, the test is blocked on something that portage has done to the environment. Does dmesg show any indication that the kernel has blocked the test from running a child process, I saw a mention of os/waitid blocking waiting for something.

…

On Wed, Dec 28, 2016 at 6:09 PM, William ***@***.***> wrote: I pointed TMPDIR to the appropriate location and still got a failure. The log is attached. It definitely looks like some kind of timeout, but I'm not sure what is causing it. build-log2.txt <https://github.com/golang/go/files/675174/build-log2.txt> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#18442 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA3X5mDmLCiMFTDfZl-gnK1v-wbR6ks5rMgsMgaJpZM4LWplO> .

[williamh]

I cleared dmesg so I wouldn't see any old messages then re-ran the build with tests enabled. Nothing appeared in dmesg.

[rsc]

The runtime test is hung waiting for gdb in TestGdbBacktrace. It runs:

gdb -nx -batch \
	-ex 'set startup-with-shell off' \
	-ex 'break main.eee' \
	-ex 'run' \
	-ex 'backtrace' \
	-ex 'continue' \
	a.exe

where a.exe is the result of compiling:

package main

//go:noinline
func aaa() bool { return bbb() }

//go:noinline
func bbb() bool { return ccc() }

//go:noinline
func ccc() bool { return ddd() }

//go:noinline
func ddd() bool { return f() }

//go:noinline
func eee() bool { return true }

var f = eee

func main() {
	_ = aaa()
}

Gdb is not exiting. Can you try running that command by hand and see why?

It is also hung waiting for gdb in TestGdbAutotmpTypes, which does a similar thing.