cmd/go: 'go test -race ...' misses race condition on go1.9.2 linux/amd64 #23276
Comments
|
@markcampanelli-wf just as per Ocam's razor, did you turn on the I ask because as in the screenshot above doesn't seem y'all turned on the Could you help us clarify and perhaps link to a Travis build with the |
|
Yes sorry (from the Makefile): go test -short -race -v -ldflags -s `go list ./...` | tee "$${ROOT:-/testing}/test_reports/go_test_results.out"
go2xunit -input "$${ROOT:-/testing}/test_reports/go_test_results.out" -output "$${ROOT:-/testing}/test_reports/go_test_results.xml"Also, CI is homegrown in a docker container on an EC2 instance. |
|
Data race reports are written to stderr, file descriptor 2, not stdout.
What is likely happening is your report is showing up in the output that
travis captures but not sent to your file
try this
go test -short -race -v ./... 2>&1 | tee
"$${ROOT:-/testing}/test_reports/go_test_results.out"
…On Fri, Dec 29, 2017 at 9:57 AM, Mark Campanelli ***@***.***> wrote:
Yes sorry:
go test -short -race -v -ldflags -s `go list ./...` | tee "$${ROOT:-/testing}/test_reports/go_test_results.out"
go2xunit -input "$${ROOT:-/testing}/test_reports/go_test_results.out" -output "$${ROOT:-/testing}/test_reports/go_test_results.xml"
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#23276 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA2lJxDiao7uE0nQkSZGW2xoHUnLcks5tFBzcgaJpZM4ROtP9>
.
|
odeke-em
added
the
WaitingForInfo
|
While including stderr is indeed wise, this didn't make a difference here. |
|
Are you sure the race actually occurs while the test function is running? An example demonstrating the actual race in question would be helpful either way. |
|
That is possible, but it was a newly added test when issue started appearing. In any event, we just grep 'WARNING: DATA RACE' now on the captured output and fail on match. |
|
I don't know what is going on here, and it does seem possible hat it could be related to the CI system in some way. In order to make progress we will need instructions on how to reproduce the problem ourselves. Thanks. |
ianlancetaylor
added
the
NeedsInvestigation
|
Been waiting for info for a while. Closing. |
andybons
changed the title
What version of Go are you using (
go version)?go1.9.2 darwin/amd64 and go1.9.2 linux/amd64
Does this issue reproduce with the latest release?
Yes, but only on go1.9.2 linux/amd64, not on go1.9.2 darwin/amd64.
What operating system and processor architecture are you using (
go env)?darwin/amd64 and linux/amd64
What did you do?
Ran
go test -race ...with a test that has repeatable race conditions.What did you expect to see?
On go1.9.2 darwin/amd64, (i.e., local dev) the race condition appears between the RUN and FAIL lines, and the failure registers in go2xunit conversion to xUnit. I would expect the same on our CI test runner machine, which is go1.9.2 linux/amd64.
What did you see instead?
On go1.9.2 linux/amd64, the data race warnings appear after the RUN and PASS lines for the offending test, but before the next test's RUN line. Exit code is zero, indicated no race(s). Subsequently, go2xunit doesn't pick up any failure OR the WARNING: DATA RACE (even with -fail-on-race flag set).
The text was updated successfully, but these errors were encountered: