Skip to content
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

Intermittent failure of static_file/file_filter_test.go: TestBasicFiles #30

Open
gnanderson opened this issue Aug 19, 2012 · 4 comments

Comments

@gnanderson
Copy link
Contributor

I've noticed an intermittent failure of this test, here's a sample log from the latest failure.

[   51s] $WORK/github.com/ngmoco/falcore/static_file/_test/static_file.test
[   52s] --- FAIL: TestBasicFiles (0.02 seconds)
[   52s]   file_filter_test.go:144: custom mime type Error GETting file:unexpected EOF

I first saw the failure on the openSUSE Factory and openSUSE Tumbleweed builders. These are our unstable and rolling release platforms respectivly so after triggering a rebuild and not seeing a direct repeat of the failure I dismissed it as an issue with an unstable platform. Subsequently I have seen the issue maybe two or three time on the current stable release builders and now on an external distro build. Seeing the issue on an external distro prompted me to upstream it.

This intermittently appears on both 32 and 64 bit archs, and across at least the following platforms, but this should be considered with the knowledge that as in intermittent failure, the openSUSE platforms are the ones that get automatically triggered to rebuild more often which increases the likelyhood of occurence.

  • openSUSE 12.2 RC
  • openSUSE Factory
  • openSUSE Tumbleweed
  • RHEL 6

A first take suggests the error can only originate from the RoundTripper use but poking at the implemtation in the std libs:
http://golang.org/src/pkg/net/http/transport.go?s=3821:3892#L116
I see that there's the use of synch primatives, so this may be a subtle failure and possibly a bug in the test rather than falcore. Additionally we run our Go builds with -p 4 to match the allocated cores on the builders, so I'm not sure if that affects things.

@dgrijalva
Copy link
Contributor

Does it always happen with the same test?

@gnanderson
Copy link
Contributor Author

Yep, you can see it happened again on a couple of builds last night:

https://build.opensuse.org/project/monitor?commit=Filter%3A&failed=1&pkgname=&repo_CentOS_CentOS-6=1&repo_Mandriva_2011=1&repo_RedHat_RHEL-6=1&repo_SLE_11_SP1=1&repo_SLE_11_SP2=1&repo_ScientificLinux_6=1&repo_openSUSE_11_4=1&repo_openSUSE_12_1=1&repo_openSUSE_12_2=1&repo_openSUSE_Factory=1&repo_openSUSE_Tumbleweed=1&arch_i586=1&arch_x86_64=1&project=devel%3Alanguages%3Ago&defaults=0

I'm unsure if it happens on the same file in the test table, I'll make the test a little more verbose and run it in a loop overnight to see if I can recreate the issue on my local build server.

@dgrijalva
Copy link
Contributor

Daves-MacBook-Air-2:falcore dgrijalva$ ruby -e "100.times{r = go test ./...; unless $? == 0; puts r; raise 'fail'; end}"
Daves-MacBook-Air-2:falcore dgrijalva$

I can't make it happen on my mac :/

-dave

On Aug 20, 2012, at 11:45 AM, Graham Anderson wrote:

Yep, you can see it happened again on a couple of builds last night:

https://build.opensuse.org/project/monitor?commit=Filter%3A&failed=1&pkgname=&repo_CentOS_CentOS-6=1&repo_Mandriva_2011=1&repo_RedHat_RHEL-6=1&repo_SLE_11_SP1=1&repo_SLE_11_SP2=1&repo_ScientificLinux_6=1&repo_openSUSE_11_4=1&repo_openSUSE_12_1=1&repo_openSUSE_12_2=1&repo_openSUSE_Factory=1&repo_openSUSE_Tumbleweed=1&arch_i586=1&arch_x86_64=1&project=devel%3Alanguages%3Ago&defaults=0

I'm unsure if it happens on the same file in the test table, I'll make the test a little more verbose and run it in a loop overnight to see if I can recreate the issue on my local build server.


Reply to this email directly or view it on GitHub.

@dgrijalva
Copy link
Contributor

Does this still happen?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants