-
Notifications
You must be signed in to change notification settings - Fork 18k
all: multiple packages fail go test when not in short mode #24464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Change https://golang.org/cl/101815 mentions this issue: |
Unused variables in closures are currently not diagnosed by the compiler (this is Issue #3059), while go/types catches them. One unused variable in the cmd/trace tests is causing the go/types test that typechecks the whole standard library to fail: FAIL: TestStdlib (8.05s) stdlib_test.go:223: cmd/trace/annotations_test.go:241:6: gcTime declared but not used FAIL Remove it. Updates #24464 Change-Id: I0f1b9db6ae1f0130616ee649bdbfdc91e38d2184 Reviewed-on: https://go-review.googlesource.com/101815 Reviewed-by: Daniel Martí <[email protected]>
|
Change https://golang.org/cl/101835 mentions this issue: |
The failure in
The tests should be made more robust. Will give it a go, but there are many ways to fix this. |
Change https://golang.org/cl/101836 mentions this issue: |
The |
Otherwise, a populated GOPATH might result in failures such as: $ go test [...] no buildable Go source files in [...]/gopherjs/compiler/natives/src/crypto/rand exit status 1 Move the initialization of the dirs walker out of the init func, so that we can control its behavior in the tests. Updates #24464. Change-Id: I4b26a7d3d6809bdd8e9b6b0556d566e7855f80fe Reviewed-on: https://go-review.googlesource.com/101836 Run-TryBot: Daniel Martí <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
I can't get
(same thing on linux) |
I can (linux/amd64), here's the log:
|
Hmm, might be a gdb version issue. I'm running 7.9. |
I get the same failure, gdb version 8.1. |
My system comes with gdb 7.12 |
Is that gdb version or presence/absence of Python scripts? |
I have gdb versions 7.9 and 8.0.1, seems to work for me. I am not super-fluent in Python, but this from runtime-gdb.py seems semi-relevant:
|
i have added links to the fixes and other discussions so far to the main post |
cmd/compile/internal/ssa fails for me with gdb 8.0.1, so the gdb version doesn't seem to be the issue. |
The underlying problem here is #12508 |
@alexd765 the SliceTypePrinter code is really old, so that's probably the same. |
@dr2chase I can reproduce it and I only have versions 2.7.14 and 3.6.4 installed. I'm running Arch Linux, so I would assume that any somewhat recent Linux system should have this test failure. I tried playing with that runtime-gdb.py file, but not even emptying the file changes the behaviour of the test. |
I am on Ubuntu 17.10 with python 2.7.14 |
Except that I am failing to reproduce the bug on Linux.... |
@dr2chase I also started to look into this a little bit: First observation: if i force the test to use delve with Then i saw that there is an option to regenerate the testdata with I can send the changes as a cl if that helps |
Mucking with the testdata files w/o understanding why we have this difference isn't going to help -- you'll break it for me, for example. Also, I have several CLs stacked up that will mess with the testdata in a big way, alleged positive. (If you actually look at what's recorded there, there's plenty of room for improvement.) |
Perhaps it is not autoloading runtime-gdb.py? I definitely need to modify the test to be better about this. |
Change https://golang.org/cl/102598 mentions this issue: |
Gdb can be sensitive to contents of .gdbinit, and to run this test properly needs to have runtime/runtime-gdb.py on the auto load safe path. Therefore, turn off .gdbinit loading and explicitly add $GOROOT/runtime to the safe load path. This should make ssa/debug_test.go run more consistently. Updates #24464. Change-Id: I63ed17c032cb3773048713ce51fca3a3f86e79b6 Reviewed-on: https://go-review.googlesource.com/102598 Run-TryBot: David Chase <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
@dr2chase all the Out of the initial 5 issues, 3 have been fixed and 2 have been split into separate issues. So it seems like there's nothing else to do here. Thanks again @alexd765 for reporting them. |
Thanks for verifying. I wasn't 100% sure, but I was hopeful. |
yeah i can confirm that |
What version of Go are you using (
go version
)?go version devel +be371edd67 Tue Mar 20 19:38:06 2018 +0000 linux/amd64
What operating system and processor architecture are you using (
go env
)?linux/amd64
What did you do?
Test all packages via all.bash (in short mode) and then via go test ./... (not in short mode)
~/gotip/src$ ./all.bash && go test ./...
Inspired by #24436
What did you expect to see?
All tests pass (in short mode)
All tests pass (not in short mode)
What did you see instead?
All tests pass (in short mode)
Multiple packages fail go test (not in short mode)
FAIL cmd/compile/internal/ssa (discussed here)
FAIL cmd/doc (fixed in cl 101836)
FAIL cmd/go (#24436)
FAIL cmd/gofmt (#24472)
FAIL go/types (fixed in cl 101815)
FAIL net
Edit: i have added links to the fixes and other discussions so far
The text was updated successfully, but these errors were encountered: