-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: TestCgoCCodeSIGPROF fails on RHEL7.2 7.2 3.10.0-313.el7.ppc64le #14732
Comments
Not sure what happens here, I haven't seen this error in a while. It seemed like a flaky problem, probably something different in the OS. We can close this if you want and if it happens again I can open a new one. It only happened on RHEL 7.2. |
I think this happens on other platforms. I just tested tip (go version devel +0ec6256) w/ https://go-review.googlesource.com/24110/ on openbsd/386 and got the following:
Without https://go-review.googlesource.com/24110/, it prints "panic: test timed out after 3m0s" and similar stack trace. |
Perhaps this issue is a duplicate of #14809. |
@mikioh Can you try to recreate this with the environment variable |
@ianlancetaylor Here you are, a 15Meg plain text file. |
Oh, bother, I'm sorry. That is the scheduling trace for the runtime.test program, but I need the scheduling trace for the program that it runs. And it's not there because How about this: change |
Looking at the test code I realized that there is a useless loop that could potentially cause an infinite loop. Please see if the problem still reproduces with https://golang.org/cl/24151. Thanks. |
CL https://golang.org/cl/24151 mentions this issue. |
@ianlancetaylor, CL 24151 doesn't fix the issue.
So far it's likely that https://go-review.googlesource.com/20219 is closely related to the issues because both #14732 and #14809 go versions include CL 20219. |
Thanks for checking. CL 24151 still seems like a good idea anyhow. 20219 is where the failing test was added, so there is a sense in which it is the cause of this issue. It doesn't really help us solve the problem, though. I'm confident that the non-test change of 20219 is not causing any trouble. |
I verified that the test fails if I undo the change that it tests for. Updates #14732. Change-Id: Ib30352580236adefae946450ddd6cd65a62b7cdf Reviewed-on: https://go-review.googlesource.com/24151 Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Mikio Hara <[email protected]>
@mikioh How easy is it to reproduce the problem on OpenBSD/386? I don't see any failures on the builder. I have not been able to reproduce this myself on any system. Any luck getting the schedule trace of the child program per the comment above? |
Pretty much on my openbsd-386 vm.
Will try this weekend. |
Here you go; TestCgoCCodeSIGPROF.txt |
Thanks for the scheduling trace. It shows that There are 7 M's. 6 have no associated P. M1 is associated with P0. M1 is locked to goroutine 17. The stack trace at the end shows only
This is probably the goroutine started by Note that although goroutine 17 is shown above as So I may see part of the problem. The program has a loop that just calls into C. Because it keeps making calls into C, Before https://golang.org/cl/24151 I think that would have been enough to hang the program. Before that CL, the program was in an infinite loop that will not get preempted. On a system with However, you are seeing this problem even after CL 24151, and I don't have an explanation for that. After that CL the program should not hang, because it should not run for more than 1 second. Does it fix the problem if you add a call |
Sure, looks like |
Still don't know what is happening here. Postponing to 1.8. |
Sometimes I have a similar problem when I rebuild from the tip, on Mac OS X (10.11.5) on MacBook 12: GOMAXPROCS=2 runtime -cpu=1,2,4--- FAIL: TestCgoCCodeSIGPROF (0.72s)
FAIL |
@YoshikiShibata That is a different problem. Could you open a new issue for it? Thanks. |
@ianlancetaylor We're halfway through Go 1.8 now; have you been able to investigate this bug yet? |
I still don't see any way this could possibly happen. @mikioh If you can still recreate this, can you get an
|
With either GOMAXPROCS=1 or greater than 1, CgoCCodeSIGPROF with tip now passes on openbsd/386. |
Thanks! I'm going to close this unless and until someone reports a reproduction on tip. |
I'm seeing this build failure only on RHEL 7.2 3.10.0-313.el7.ppc64le. I've successfully built on another RHEL7.2 with a later kernel as well as other distros without the error. I know there was a restriction on certain Linux kernel versions but couldn't find where that is documented.
Please answer these questions before submitting your issue. Thanks!
go version
)?Failure starts with this commit and continues to happen with latest
go version devel +1716162 Fri Mar 4 21:06:31 2016 +0000 linux/ppc64le
go env
)?RHEL 7.2 ppc64le
3.10.0-313.el7.ppc64le cmd/cgo: fails with gcc 4.4.1 #1 SMP Tue Sep 1 00:35:49 EDT 2015 ppc64le ppc64le ppc64le GNU/Linux
Note that I am only seeing this failure on this system. I've built on various Ubuntu systems, a SLES12 and even another RHEL 7.2 system with a different Linux version without the failure.
Pulled the golang master source from this commit and tried to build using src/all.bash.
Everything building and all tests finished, ending with:
ALL TESTS PASSED
panic: test timed out after 3m0s
The text was updated successfully, but these errors were encountered: