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
TestHttpInsecure timeout on the openbsd-amd64 builder #328
Comments
/cc @nolanmar511, since this seems somewhat similar to #300. |
Also note that this looks like a test flake - if it were failing every single time, the vendored version wouldn't have been updated. |
Working on reproducing.
|
@nolanmar Looks like it tries to resolve |
This is the only entry in /etc/hosts
|
Thanks -- was able to modify /etc/hosts to get test to pass. Currently running the test to try to reproduce the flake. |
Haven't been able to reproduce on a freebsd GCE instance. Test is now passing. |
I think that maybe if I shorten the duration of the profile collected, then this might be more reproducible. @mvdan -- Any idea how often this fails? |
It doesn't look like it happens often. For example, look at the openbsd columns in https://build.golang.org/ - they're almost entirely green. I went through the most recent four pages of the build history and found no other occurrences. Noone raised an issue about this flake on the Go issue tracker either, so it's unlikely that many others ran into the same flake. Although it would be quite the coincidence if I was the only one to run into the flake. |
@nolanmar511 Here is another pprof test failure I just spotted: https://build.golang.org/log/227d9194d392913ea91f96c9085cad59a7274ec7 |
The other pprof test failure has this error message:
So TestHttpsInsecure may be flaky in multiple ways. |
Just got the initial flake again: https://storage.googleapis.com/go-build-log/329c11d9/openbsd-amd64-62_8f3e4ede.log |
I have been able to run this test on gomote, and ran the test about 200 times, and did not see this failure. |
@nolanmar511 you might be interested in @josharian's findings here: golang/go#24611 I also suggest that you use the |
I reproduced a variant of this issue with a command like
on a x86_64 linux machine. The error I got is
which I think we saw before. I was first confused here about why running this test on a stressed core would produce unsymbolized profile, but then realized that what really happens is that we get a profile with no samples at all - apparently when the system is stressed enough it may happen so that the code in the test that is supposed to generate some CPU usage doesn't get a chance to execute at all. I verified it by making a local change like
and running same stress command again saw expected error
Anyway, what I think I am going to do is switch this test to use a different profile type, like goroutine. Trying to test against the CPU profile type has been too much trouble so far, and this test is really just an attempt to test end-to-end an https fetch in pprof so it's not that important which profile type we use. |
Trying to test against /debug/pprof/profile has been giving some flakes and trouble so far (google#146, google#253, google#328, golang/go#24611, golang/go#22594). While some of the discussions the failures triggered appear to be useful (such as whether CPU profiles are expected to be working on Windows XP or not), that kind of testing is not really in the scope for this particular test. This change switches the test to use goroutine profile instead which is hopefully much less dependent on the environment. The change also makes the test much faster to run.
I think #350 will fix the issue. |
Feel free to close this issue as fixed if you're confident you fixed it, but I'd wait for Josh to clarify what error he got on the other issue (before marking that one as closed too). I just imagined they are duplicates, but I have no confirmation. |
Sorry, AFK for a while. Yes, all my failures were of the “no samples” variety. Could that PR also now safely reduce the sample collection time from 10s to something much smaller? Thanks for working on this. |
@josharian PR #350 switches the test to use goroutine profile instead of CPU so 10s thing is not relevant now (goroutine profile is instant). |
Trying to test against /debug/pprof/profile has been giving some flakes and trouble so far (#146, #253, #328, golang/go#24611, golang/go#22594). While some of the discussions the failures triggered appear to be useful (such as whether CPU profiles are expected to be working on Windows XP or not), that kind of testing is not really in the scope for this particular test. This change switches the test to use goroutine profile instead which is hopefully much less dependent on the environment. The change also makes the test much faster to run.
I am fairly certain this is fixed. |
Trying to test against /debug/pprof/profile has been giving some flakes and trouble so far (google#146, google#253, google#328, golang/go#24611, golang/go#22594). While some of the discussions the failures triggered appear to be useful (such as whether CPU profiles are expected to be working on Windows XP or not), that kind of testing is not really in the scope for this particular test. This change switches the test to use goroutine profile instead which is hopefully much less dependent on the environment. The change also makes the test much faster to run.
Full log: https://storage.googleapis.com/go-build-log/198cc863/openbsd-amd64-62_382c8558.log
Interesting part:
This is with the vendored version in the Go tree, which is 0e0e5b7.
Also, the tests are very noisy. Is this intended? You can see that the rest of the standard library tests are all quiet by default, as they should be. Perhaps these logs should be hidden behind
testing.Verbose()
.The text was updated successfully, but these errors were encountered: