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

runtime: proc_test timed out on TestPreemptionAfterSyscall on windows/386 #34901

Closed
toothrot opened this issue Oct 14, 2019 · 4 comments
Closed

Comments

@toothrot
Copy link
Contributor

@toothrot toothrot commented Oct 14, 2019

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

$ go version
go version go1.13.1 windows/386 # http://golang.org/cl/201060 

Does this issue reproduce with the latest release?

This failure is specifically on release-branch.go1.13, from this cl: http://golang.org/cl/201060

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

go env Output
$ go env
"GOBUILDEXIT=1"
"=C:=C:\\golang"
"ALLUSERSPROFILE=C:\\ProgramData"
"APPDATA=C:\\Users\\gopher\\AppData\\Roaming"
"CommonProgramFiles=C:\\Program Files\\Common Files"
"CommonProgramFiles(x86)=C:\\Program Files (x86)\\Common Files"
"CommonProgramW6432=C:\\Program Files\\Common Files"
"COMPUTERNAME=SERVER-2008R2-V"
"ComSpec=C:\\Windows\\system32\\cmd.exe"
"FP_NO_HOST_CHECK=NO"
"GooGetRoot=C:\\ProgramData\\GooGet"
"GOROOT_BOOTSTRAP=C:\\workdir\\go1.4"
"HOMEDRIVE=C:"
"HOMEPATH=\\Users\\gopher"
"LOCALAPPDATA=C:\\Users\\gopher\\AppData\\Local"
"LOGONSERVER=\\\\SERVER-2008R2-V"
"NUMBER_OF_PROCESSORS=4"
"OS=Windows_NT"
"PATH=C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\ProgramData\\GooGet;C:\\Program Files\\Google\\Compute Engine\\metadata_scripts;C:\\Program Files (x86)\\Google\\Cloud SDK\\google-cloud-sdk\\bin;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files\\Google\\Compute Engine\\sysprep;C:\\godep\\gcc32\\bin"
"PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"
"PROCESSOR_ARCHITECTURE=AMD64"
"PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 63 Stepping 0, GenuineIntel"
"PROCESSOR_LEVEL=6"
"PROCESSOR_REVISION=3f00"
"ProgramData=C:\\ProgramData"
"ProgramFiles=C:\\Program Files"
"ProgramFiles(x86)=C:\\Program Files (x86)"
"ProgramW6432=C:\\Program Files"
"PROMPT=$P$G"
"PSModulePath=C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\;C:\\Program Files (x86)\\Google\\Cloud SDK\\google-cloud-sdk\\platform\\PowerShell"
"PUBLIC=C:\\Users\\Public"
"SESSIONNAME=Console"
"SystemDrive=C:"
"SystemRoot=C:\\Windows"
"TEMP=C:\\Users\\gopher\\AppData\\Local\\Temp"
"TMP=C:\\Users\\gopher\\AppData\\Local\\Temp"
"USERDOMAIN=SERVER-2008R2-V"
"USERDOMAIN_ROAMINGPROFILE=SERVER-2008R2-V"
"USERNAME=gopher"
"USERPROFILE=C:\\Users\\gopher"
"windir=C:\\Windows"
"windows_tracing_flags=3"
"windows_tracing_logfile=C:\\BVTBin\\Tests\\installpackage\\csilogfile.log"
"GO_STAGE0_NET_DELAY=21.3s"
"GO_STAGE0_DL_DELAY=200ms"
"WORKDIR=C:\\workdir"
"GO_BUILDER_NAME=windows-386-2008"
"GOARCH=386"
"GOHOSTARCH=386"
"GOBIN="

What did you do?

Ran trybots for http://golang.org/cl/201060

The CL updates prove.go to correct an issue with negative indexes on slices.

What did you expect to see?

Success

What did you see instead?

The trybot run failed on a test for goroutine premption in tight loops around system calls. I don't feel like this test is related to the change.

A subsequent trybot run passed.

##### GOMAXPROCS=2 runtime -cpu=1,2,4 -quick
--- FAIL: TestPreemptionAfterSyscall (3.23s)
    --- FAIL: TestPreemptionAfterSyscall/1ms (3.10s)
        proc_test.go:967: timeout exceeded: 3.0976562s (3s)
FAIL
FAIL	runtime	58.635s
FAIL
2019/10/14 17:34:34 Failed: exit status 1
2019/10/14 17:34:34 FAILED

Full Trybot log:
https://storage.googleapis.com/go-build-log/def5eb7b/windows-386-2008_29aaa38e.log

@toothrot
Copy link
Contributor Author

@toothrot toothrot commented Oct 14, 2019

Test was implemented as part of #10958

/cc @avagin

@toothrot toothrot added this to the Backlog milestone Oct 14, 2019
@bcmills
Copy link
Member

@bcmills bcmills commented Nov 8, 2019

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 14, 2019

We haven't seen any failures in the last five days, but we used to see multiple failures per day. I'm not sure what fixed this, but it is almost certainly fixed.

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

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.