aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/race/output_test.go
AgeCommit message (Collapse)Author
2026-03-30runtime/race: allow TestOutput output in either orderMichael Pratt
We have only seen the wrappersym case reported in the opposite order in practice, but since these are intentionally racy, they could theoretically all occur in the opposite order. It would be nice to have a bit more structure to these tests so the test itself could easily flip the order. However, since they are just regular expressions, for now I've simply listed both orders. Fixes #78394. Change-Id: I92e04127f275c2394a12d63d2f2a3ce56a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/761161 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-03-27runtime/race: use subtests for TestOutputMichael Pratt
For #78394. Change-Id: I4ef1a299f37e2b6532e2008378aca3aa6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/760308 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com>
2024-08-01cmd/compile: add race instrumentation during walkCompareCuong Manh Le
So the racy usage could be detected after re-writing "==" to runtime.memequal call. Updates #61204 Change-Id: Idb4ac37e55813cc87f9d16aa656fb447edf69ea1 Reviewed-on: https://go-review.googlesource.com/c/go/+/601117 Reviewed-by: Egon Elbre <egonelbre@gmail.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-10-25testing: use monotonic counts to attribute races in subtestsBryan C. Mills
This implements the approach I described in https://go-review.git.corp.google.com/c/go/+/494057/1#message-5c9773bded2f89b4058848cb036b860aa6716de3. Specifically: - Each level of test atomically records the cumulative number of races seen as of the last race-induced test failure. - When a subtest fails, it logs the race error, and then updates its parents' counters so that they will not log the same error. - We check each test or benchmark for races before it starts running each of its subtests or sub-benchmark, before unblocking parallel subtests, and after running any cleanup functions. With this implementation, it should be the case that every test that is running when a race is detected reports that race, and any race reported for a subtest is not redundantly reported for its parent. The regression tests are based on those added in CL 494057 and CL 501895, with a few additions based on my own review of the code. Fixes #60083. Change-Id: I578ae929f192a7a951b31b17ecb560cbbf1ef7a1 Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-race,gotip-windows-amd64-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/506300 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-08-17cmd/compile/internal/typecheck: normalize go/defer statements earlierMatthew Dempsky
Normalizing go/defer statements to always use functions with zero parameters and zero results was added to escape analysis, because that was the earliest point at which all three frontends converged. Now that we only have the unified frontend, we can do it during typecheck, which is where we perform all other desugaring and normalization rewrites. Change-Id: Iebf7679b117fd78b1dffee2974bbf85ebc923b23 Reviewed-on: https://go-review.googlesource.com/c/go/+/520260 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-05-23runtime: symbolize wrappers as a last resort in race tracebacksAustin Clements
CL 466099 rewrote stack symbolization in race reports. Prior to this CL, physical frames consisting entirely of wrapper logical frame would print the wrapper, even though in other cases we try to avoid printing wrappers. CL 466099 unintentionally changed this behavior and now physical frames consisting entirely of wrapper frames instead fail to symbolize and print "??()". Fix this by taking the outermost wrapper frame if the entire logical frame expansion consists of wrappers. Fixes #60245. Change-Id: I13de8857e508b757ea10d1fc7a47258d7fddbfdb Reviewed-on: https://go-review.googlesource.com/c/go/+/497235 Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Auto-Submit: Austin Clements <austin@google.com>
2022-01-14runtime/race: be less picky about test run timeAustin Clements
Currently, there are two regexps in the race detector output tests that assume subtests will complete in < 1 second. This isn't necessary and very occasionally fails (on builders that are probably very loaded). Make these tests less picky about timing. Fixes #50612. Change-Id: Ib3f94d6c5dc37541dbeb06de71cf462a74af844b Reviewed-on: https://go-review.googlesource.com/c/go/+/378581 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-10-28all: go fix -fix=buildtag std cmd (except for bootstrap deps, vendor)Russ Cox
When these packages are released as part of Go 1.18, Go 1.16 will no longer be supported, so we can remove the +build tags in these files. Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs as defined in src/cmd/dist/buildtool.go, which need to continue to build with Go 1.4 for now. Also reverted src/vendor and src/cmd/vendor, which will need to be updated in their own repos first. Manual changes in runtime/pprof/mprof_test.go to adjust line numbers. For #41184. Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e Reviewed-on: https://go-review.googlesource.com/c/go/+/344955 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-06-05[dev.typeparams] runtime/race: make test compatible with types2Matthew Dempsky
types2 correctly distinguishes variable assignment from use even within function literals. Whatever the outcome of #3059, the test cases in runtime/race need to be fixed to accomodate that. Change-Id: Ibe3547f07b681ff41225caabaf050872a48c98d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/325030 Trust: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
2021-04-08runtime: replace os.MkdirTemp with T.TempDirianwoolf
Updates #45402 Change-Id: I3aa82fc2486b4de49b45388bbab24f5ffe558f91 Reviewed-on: https://go-review.googlesource.com/c/go/+/307989 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Tobias Klauser <tobias.klauser@gmail.com>
2021-03-23cmd/compile: wrap/desugar defer calls for register abiThan McIntosh
Adds code to the compiler's "order" phase to rewrite go and defer statements to always be argument-less. E.g. defer f(x,y) => x1, y1 := x, y defer func() { f(x1, y1) } This transformation is not beneficial on its own, but it helps simplify runtime defer handling for the new register ABI (when invoking deferred functions on the panic path, the runtime doesn't need to manage the complexity of determining which args to pass in register vs memory). This feature is currently enabled by default if GOEXPERIMENT=regabi or GOEXPERIMENT=regabidefer is in effect. Included in this CL are some workarounds in the runtime to insure that "go" statement targets in the runtime are argument-less already (since wrapping them can potentially introduce heap-allocated closures, which are currently not allowed). The expectation is that these workarounds will be temporary, and can go away once we either A) change the rules about heap-allocated closures, or B) implement some other scheme for handling go statements. Change-Id: I01060d79a6b140c6f0838d6e6813f807ccdca319 Reviewed-on: https://go-review.googlesource.com/c/go/+/298669 Trust: Than McIntosh <thanm@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
2021-02-20all: go fmt std cmd (but revert vendor)Russ Cox
Make all our package sources use Go 1.17 gofmt format (adding //go:build lines). Part of //go:build change (#41184). See https://golang.org/design/draft-gobuild Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/294430 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-12-22[dev.regabi] runtime/race: adjust test pattern match for ABI wrapperThan McIntosh
Adjust the pattern matching in one of the race output test to allow for the possible introduction of an ABI wrapper. Normally for tests that match traceback output wrappers are not an issue since they are screened out by Go's traceback mechanism, but in this case the race runtime is doing the unwinding, so the wrapper may be visible. Change-Id: I45413b5c4701d4c28cc760fccc8203493dbe2874 Reviewed-on: https://go-review.googlesource.com/c/go/+/278756 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Trust: Than McIntosh <thanm@google.com>
2020-12-14test: make a race detector test robust to timing variationsDaniel S Fava
The `external_cgo_thread` test in `runtime/race/output_test.go` was producing intermittent failures. The test was performing a sleep, which may not be enough depending on how long it takes to setup the callBack goroutine. Added a synchronization to make sure callBack finishes before main ends. Whether the increment to racy++ happens first in the callBack or in main doesn't matter: the race detector should flag the race regardless. The output check was changed so that the test passes regardless of which increment occurs first. Fixes #43008 Change-Id: I325ec3dea52b3725e739fbf2bd7ae92875d2de10 Reviewed-on: https://go-review.googlesource.com/c/go/+/276752 Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Ian Lance Taylor <iant@golang.org>
2020-12-09all: update to use os.ReadFile, os.WriteFile, os.CreateTemp, os.MkdirTempRuss Cox
As part of #42026, these helpers from io/ioutil were moved to os. (ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.) Update the Go tree to use the preferred names. As usual, code compiled with the Go 1.4 bootstrap toolchain and code vendored from other sources is excluded. ReadDir changes are in a separate CL, because they are not a simple search and replace. For #42026. Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/266365 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-11-13runtime: swap the order of raceacquire() and racerelease()Daniel S Fava
In chansend() and chanrecv() of chan.go, the order of calls to raceacquire() and racerelease() was swapped, which meant that the code was not following the memory model "by the letter of the law." Similar for bufrecv and bufsend in select.go The memory model says: - A send happens before the corresponding receive completes, and - the kth receive on a channel with capacity C happens before the k+C send on that channel completes. The operative word here is "completes." For example, a sender obtains happens-before information on completion of the send-operation, which means, after the sender has deposited its message onto the channel. Similarly for receives. If the order of raceacquire() and racerelease() is incorrect, the race detector may fail to report some race conditions. The fix is minimal from the point of view of Go. The fix does, however, rely on a new function added to TSan: https://reviews.llvm.org/D76322 This commit only affects execution when race detection is enabled. Added two tests into `runtime/race/output_test.go`: - `chanmm` tests for the issue addressed by this patch - `mutex` is a test for inverted semaphores, which must not be broken by this (or any other) patch Fixes #37355 Change-Id: I5e886879ead2bd456a4b7dd1d17253641b767f63 Reviewed-on: https://go-review.googlesource.com/c/go/+/220419 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Trust: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2020-10-26runtime,cmd/cgo: simplify C -> Go call pathAustin Clements
This redesigns the way calls work from C to exported Go functions. It removes several steps from the call path, makes cmd/cgo no longer sensitive to the Go calling convention, and eliminates the use of reflectcall from cgo. In order to avoid generating a large amount of FFI glue between the C and Go ABIs, the cgo tool has long depended on generating a C function that marshals the arguments into a struct, and then the actual ABI switch happens in functions with fixed signatures that simply take a pointer to this struct. In a way, this CL simply pushes this idea further. Currently, the cgo tool generates this argument struct in the exact layout of the Go stack frame and depends on reflectcall to unpack it into the appropriate Go call (even though it's actually reflectcall'ing a function generated by cgo). In this CL, we decouple this struct from the Go stack layout. Instead, cgo generates a Go function that takes the struct, unpacks it, and calls the exported function. Since this generated function has a generic signature (like the rest of the call path), we don't need reflectcall and can instead depend on the Go compiler itself to implement the call to the exported Go function. One complication is that syscall.NewCallback on Windows, which converts a Go function into a C function pointer, depends on cgocallback's current dynamic calling approach since the signatures of the callbacks aren't known statically. For this specific case, we continue to depend on reflectcall. Really, the current approach makes some overly simplistic assumptions about translating the C ABI to the Go ABI. Now we're at least in a much better position to do a proper ABI translation. For comparison, the current cgo call path looks like: GoF (generated C function) -> crosscall2 (in cgo/asm_*.s) -> _cgoexp_GoF (generated Go function) -> cgocallback (in asm_*.s) -> cgocallback_gofunc (in asm_*.s) -> cgocallbackg (in cgocall.go) -> cgocallbackg1 (in cgocall.go) -> reflectcall (in asm_*.s) -> _cgoexpwrap_GoF (generated Go function) -> p.GoF Now the call path looks like: GoF (generated C function) -> crosscall2 (in cgo/asm_*.s) -> cgocallback (in asm_*.s) -> cgocallbackg (in cgocall.go) -> cgocallbackg1 (in cgocall.go) -> _cgoexp_GoF (generated Go function) -> p.GoF Notably: 1. We combine _cgoexp_GoF and _cgoexpwrap_GoF and move the combined operation to the end of the sequence. This combined function also handles reflectcall's previous role. 2. We combined cgocallback and cgocallback_gofunc since the only purpose of having both was to convert a raw PC into a Go function value. We instead construct the Go function value in cgocallbackg1. 3. cgocallbackg1 no longer reaches backwards through the stack to get the arguments to cgocallback_gofunc. Instead, we just pass the arguments down. 4. Currently, we need an explicit msanwrite to mark the results struct as written because reflectcall doesn't do this. Now, the results are written by regular Go assignments, so the Go compiler generates the necessary MSAN annotations. This also means we no longer need to track the size of the arguments frame. Updates #40724, since now we don't need to teach cgo about the register ABI or change how it uses reflectcall. Change-Id: I7840489a2597962aeb670e0c1798a16a7359c94f Reviewed-on: https://go-review.googlesource.com/c/go/+/258938 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-10-18runtime/race: add test for midstack inliningKeith Randall
Add test to make sure we get the right traceback when mid-stack inlining. Update #33309 Change-Id: I23979cbe6b12fad105dbd26698243648aa86a354 Reviewed-on: https://go-review.googlesource.com/c/go/+/195984 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2018-06-01all: update comment URLs from HTTP to HTTPS, where possibleTim Cooper
Each URL was manually verified to ensure it did not serve up incorrect content. Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df Reviewed-on: https://go-review.googlesource.com/115798 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
2017-11-09cmd/go: implement per-package asmflags, gcflags, ldflags, gccgoflagsRuss Cox
It has always been problematic that there was no way to specify tool flags that applied only to the build of certain packages; it was only to specify flags for all packages being built. The usual workaround was to install all dependencies of something, then build just that one thing with different flags. Since the dependencies appeared to be up-to-date, they were not rebuilt with the different flags. The new content-based staleness (up-to-date) checks see through this trick, because they detect changes in flags. This forces us to address the underlying problem of providing a way to specify per-package flags. The solution is to allow -gcflags=pattern=flags, which means that flags apply to packages matching pattern, in addition to the usual -gcflags=flags, which is now redefined to apply only to the packages named on the command line. See #22527 for discussion and rationale. Fixes #22527. Change-Id: I6716bed69edc324767f707b5bbf3aaa90e8e7302 Reviewed-on: https://go-review.googlesource.com/76551 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-11-03cmd/go: run vet automatically during go testRuss Cox
This CL adds an automatic, limited "go vet" to "go test". If the building of a test package fails, vet is not run. If vet fails, the test is not run. The goal is that users don't notice vet as part of the "go test" process at all, until vet speaks up and says something important. This should help users find real problems in their code faster (vet can just point to them instead of needing to debug a test failure) and expands the scope of what kinds of things vet can help with. The "go vet" runs in parallel with the linking of the test binary, so for incremental builds it typically does not slow the overall "go test" at all: there's spare machine capacity during the link. all.bash has less spare machine capacity. This CL increases the time for all.bash on my laptop from 4m41s to 4m48s (+2.5%) To opt out for a given run, use "go test -vet=off". The vet checks used during "go test" are a subset of the full set, restricted to ones that are 100% correct and therefore acceptable to make mandatory. In this CL, that set is atomic, bool, buildtags, nilfunc, and printf. Including printf is debatable, but I want to include it for now and find out what needs to be scaled back. (It already found one real problem in package os's tests that previous go vet os had not turned up.) Now that we can rely on type information it may be that printf should make its function-name-based heuristic less aggressive and have a whitelist of known print/printf functions. Determining the exact set for Go 1.10 is #18085. Running vet also means that programs now have to type-check with both cmd/compile and go/types in order to pass "go test". We don't start vet until cmd/compile has built the test package, so normally the added go/types check doesn't find anything. However, there is at least one instance where go/types is more precise than cmd/compile: declared and not used errors involving variables captured into closures. This CL includes a printf fix to os/os_test.go and many declared and not used fixes in the race detector tests. Fixes #18084. Change-Id: I353e00b9d1f9fec540c7557db5653e7501f5e1c9 Reviewed-on: https://go-review.googlesource.com/74356 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-10-31cmd/go: trim objdir, not just workdir, from object filesRuss Cox
Otherwise the new numbered directories like b028/ appear in the objects, and they can change from run to run. Fixes #22514. Change-Id: I8d0cf65f3622e48b2547d5757febe0ee1301e2ed Reviewed-on: https://go-review.googlesource.com/74791 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
2017-10-31runtime/race: install alternate packages to temp dirRuss Cox
The content-based staleness code means that go run -gcflags=-l helloworld.go recompiles all of helloworld.go's dependencies with -gcflags=-l, whereas before it would have assumed installed packages were up-to-date. In this test, that means every race iteration rebuilds the runtime and maybe a few other packages. Instead, install them to a temporary location for reuse. This speeds the test from 17s to 9s on my MacBook Pro. Change-Id: Ied136ce72650261083bb19cc7dee38dac0ad05ca Reviewed-on: https://go-review.googlesource.com/73992 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-08-15testing: don't fail all tests after racy test failureIan Lance Taylor
The code was adding race.Errors to t.raceErrors before checking Failed, but Failed was using t.raceErrors+race.Errors. We don't want to change Failed, since that would affect tests themselves, so modify the harness to not unnecessarily change t.raceErrors. Updates #19851 Fixes #21338 Change-Id: I7bfdf281f90e045146c92444f1370d55c45221d4 Reviewed-on: https://go-review.googlesource.com/54050 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-04-10testing: consider a test failed after race errorsCaleb Spare
Fixes #19851. Change-Id: I5ee9533406542be7d5418df154f6134139e75892 Reviewed-on: https://go-review.googlesource.com/39890 Run-TryBot: Caleb Spare <cespare@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2016-11-07runtime/race: allow TestFail to run longer than 0.00sAlex Brainman
Fixes #17811 Change-Id: I7bf9cbc5245417047ad28a14d9b9ad6592607d3d Reviewed-on: https://go-review.googlesource.com/32774 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-03testing: mark tests and benchmarks failed if a race occurs during executionRuss Cox
Before: $ go test -race -v -run TestRace === RUN TestRace ================== WARNING: DATA RACE Write at 0x00c420076420 by goroutine 7: _/Users/rsc/go/src/cmd/go/testdata/src/testrace.TestRace.func1() /Users/rsc/go/src/cmd/go/testdata/src/testrace/race_test.go:10 +0x3b Previous write at 0x00c420076420 by goroutine 6: _/Users/rsc/go/src/cmd/go/testdata/src/testrace.TestRace() /Users/rsc/go/src/cmd/go/testdata/src/testrace/race_test.go:13 +0xcc testing.tRunner() /Users/rsc/go/src/testing/testing.go:656 +0x104 Goroutine 7 (running) created at: _/Users/rsc/go/src/cmd/go/testdata/src/testrace.TestRace() /Users/rsc/go/src/cmd/go/testdata/src/testrace/race_test.go:12 +0xbb testing.tRunner() /Users/rsc/go/src/testing/testing.go:656 +0x104 Goroutine 6 (running) created at: testing.(*T).Run() /Users/rsc/go/src/testing/testing.go:693 +0x536 testing.runTests.func1() /Users/rsc/go/src/testing/testing.go:877 +0xaa testing.tRunner() /Users/rsc/go/src/testing/testing.go:656 +0x104 testing.runTests() /Users/rsc/go/src/testing/testing.go:883 +0x4ac testing.(*M).Run() /Users/rsc/go/src/testing/testing.go:818 +0x1c3 main.main() _/Users/rsc/go/src/cmd/go/testdata/src/testrace/_test/_testmain.go:42 +0x20f ================== --- PASS: TestRace (0.00s) PASS Found 1 data race(s) FAIL _/Users/rsc/go/src/cmd/go/testdata/src/testrace 1.026s $ After: $ go test -race -v -run TestRace === RUN TestRace ================== WARNING: DATA RACE Write at 0x00c420076420 by goroutine 7: _/Users/rsc/go/src/cmd/go/testdata/src/testrace.TestRace.func1() /Users/rsc/go/src/cmd/go/testdata/src/testrace/race_test.go:10 +0x3b Previous write at 0x00c420076420 by goroutine 6: _/Users/rsc/go/src/cmd/go/testdata/src/testrace.TestRace() /Users/rsc/go/src/cmd/go/testdata/src/testrace/race_test.go:13 +0xcc testing.tRunner() /Users/rsc/go/src/testing/testing.go:656 +0x104 Goroutine 7 (running) created at: _/Users/rsc/go/src/cmd/go/testdata/src/testrace.TestRace() /Users/rsc/go/src/cmd/go/testdata/src/testrace/race_test.go:12 +0xbb testing.tRunner() /Users/rsc/go/src/testing/testing.go:656 +0x104 Goroutine 6 (running) created at: testing.(*T).Run() /Users/rsc/go/src/testing/testing.go:693 +0x536 testing.runTests.func1() /Users/rsc/go/src/testing/testing.go:877 +0xaa testing.tRunner() /Users/rsc/go/src/testing/testing.go:656 +0x104 testing.runTests() /Users/rsc/go/src/testing/testing.go:883 +0x4ac testing.(*M).Run() /Users/rsc/go/src/testing/testing.go:818 +0x1c3 main.main() _/Users/rsc/go/src/cmd/go/testdata/src/testrace/_test/_testmain.go:42 +0x20f ================== --- FAIL: TestRace (0.00s) testing.go:609: race detected during execution of test FAIL FAIL _/Users/rsc/go/src/cmd/go/testdata/src/testrace 0.022s $ Fixes #15972. Change-Id: Idb15b8ab81d65637bb535c7e275595ca4a6e450e Reviewed-on: https://go-review.googlesource.com/32615 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-09-25runtime/race: don't crash on invalid PCsDmitry Vyukov
Currently raceSymbolizeCode uses funcline, which is internal runtime function which crashes on incorrect PCs. Use FileLine instead, it is public and does not crash on invalid data. Note: FileLine returns "?" file on failure. That string is not NUL-terminated, so we need to additionally check what FileLine returns. Fixes #17190 Change-Id: Ic6fbd4f0e68ddd52e9b2dd25e625b50adcb69a98 Reviewed-on: https://go-review.googlesource.com/29714 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-08-30all: use testing.GoToolPath instead of "go"Keith Randall
This change makes sure that tests are run with the correct version of the go tool. The correct version is the one that we invoked with "go test", not the one that is first in our path. Fixes #16577 Change-Id: If22c8f8c3ec9e7c35d094362873819f2fbb8559b Reviewed-on: https://go-review.googlesource.com/28089 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-05-03runtime: per-P contexts for race detectorDmitry Vyukov
Race runtime also needs local malloc caches and currently uses a mix of per-OS-thread and per-goroutine caches. This leads to increased memory consumption. But more importantly cache of synchronization objects is per-goroutine and we don't always have goroutine context when feeing memory in GC. As the result synchronization object descriptors leak (more precisely, they can be reused if another synchronization object is recreated at the same address, but it does not always help). For example, the added BenchmarkSyncLeak has effectively runaway memory consumption (based on a real long running server). This change updates race runtime with support for per-P contexts. BenchmarkSyncLeak now stabilizes at ~1GB memory consumption. Long term, this will allow us to remove race runtime dependency on glibc (as malloc is the main cornerstone). I've also implemented a different scheme to pass P context to race runtime: scheduler notified race runtime about association between G and P by calling procwire(g, p)/procunwire(g, p). But it turned out to be very messy as we have lots of places where the association changes (e.g. syscalls). So I dropped it in favor of the current scheme: race runtime asks scheduler about the current P. Fixes #14533 Change-Id: Iad10d2f816a44affae1b9fed446b3580eafd8c69 Reviewed-on: https://go-review.googlesource.com/19970 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-02-25runtime: fix getcallerpc argsDmitry Vyukov
Change-Id: I6b14b8eecf125dd74bd40f4e7fff6b49de150e42 Reviewed-on: https://go-review.googlesource.com/19897 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2016-01-27runtime/race: run tests with GOMAXPROCS=1Dmitry Vyukov
We set GOMAXPROCS=1 to prevent test flakiness. There are two sources of flakiness: 1. Some tests rely on particular execution order. If the order is different, race does not happen at all. 2. Ironically, ThreadSanitizer runtime contains a logical race condition that can lead to false negatives if racy accesses happen literally at the same time. Tests used to work reliably in the good old days of GOMAXPROCS=1. So let's set it for now. A more reliable solution is to explicitly annotate tests with required execution order by means of a special "invisible" synchronization primitive (that's what is done for C++ ThreadSanitizer tests). This is issue #14119. This reduces flakes on RaceAsFunc3 test from 60/3000 to 1/3000. Fixes #14086 Fixes #14079 Fixes #14035 Change-Id: Ibaec6b2b21e27b62563bffbb28473a854722cf41 Reviewed-on: https://go-review.googlesource.com/18968 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2015-03-28os: give race detector chance to override Exit(0)Dmitry Vyukov
Racy tests do not fail currently, they do os.Exit(0). So if you run go test without -v, you won't even notice. This was probably introduced with testing.TestMain. Racy programs do not have the right to finish successfully. Change-Id: Id133d7424f03d90d438bc3478528683dd02b8846 Reviewed-on: https://go-review.googlesource.com/4371 Reviewed-by: Russ Cox <rsc@golang.org>
2014-09-08build: move package sources from src/pkg to srcRuss Cox
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg.