- 05 Feb, 2016 3 commits
-
-
Brad Fitzpatrick authored
Change-Id: I93201fa4152f2d60b3eedb8d321a152819033121 Reviewed-on: https://go-review.googlesource.com/19270Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev 493a262 for https://golang.org/cl/19223 Fixes #14227 Change-Id: I626122811138fb3d88e4eea83f8da3fdcf91e0dc Reviewed-on: https://go-review.googlesource.com/19250Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates #14227 Change-Id: If39f11471ecd307c9483f64e73f9c89fe906ae71 Reviewed-on: https://go-review.googlesource.com/19222Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
- 04 Feb, 2016 4 commits
-
-
Keith Randall authored
When using a stack-allocated buffer for the result, don't expose the uninitialized portion of it by restricting its capacity to its length. The other option is to zero the portion between len and cap. That seems like more work, but might be worth it if the caller then appends some stuff to the result. But this close to 1.6, I'm inclined to do the simplest fix possible. Fixes #14232 Change-Id: I21c50d3cda02fd2df4d60ba5e2cfe2efe272f333 Reviewed-on: https://go-review.googlesource.com/19231Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Andrew Gerrand authored
The plan9.bell-labs.com site has fallen into disrepair. We'll instead use the site maintained by contributor David du Colombier. Fixes #14233 Change-Id: I0c702e5d3b091cccd42b288ea32f34d507a4733d Reviewed-on: https://go-review.googlesource.com/19240Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: David du Colombier <0intro@gmail.com>
-
Ian Lance Taylor authored
Update #14063. Change-Id: Id13456deb15c90a8af282b77d78ff5cdbd1de8bf Reviewed-on: https://go-review.googlesource.com/19208 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Fixes #14219. Change-Id: Id398dcfe6e9978d7eefddcdaaaa2256c16237cf3 Reviewed-on: https://go-review.googlesource.com/19207 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
-
- 03 Feb, 2016 5 commits
-
-
Brad Fitzpatrick authored
libcurl sends this (despite never being standardized), and the Google GFE rejects it with a 400 bad request (but only when over http2?). So nuke it. Change-Id: I3fc95523d50f33a0e23bb26b9195f70ab0aed0f4 Reviewed-on: https://go-review.googlesource.com/19184Reviewed-by: Chris Broadfoot <cbro@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Previous flakes: https://build.golang.org/log/223365dedb6b6aa0cfdf5afd0a50fd433a16bade https://build.golang.org/log/edbea4cd3f24e707ef2ae8378559bb0fcc453c22 Dmitry says in email about this: > The stack trace points to it pretty clearly. Done can indeed unblock > Wait first and then panic. I guess we need to recover after first > Done as well. And it looks like TestWaitGroupMisuse2 was already hardened against this. Do the same in TestWaitGroupMisuse3. Change-Id: I317800c7e46f13c97873f0873c759a489dd5f47d Reviewed-on: https://go-review.googlesource.com/19183Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
The loading of zversion.go was expecting it to be in package runtime, but it moved to runtime/internal/sys. Worse, the load was not checking the error. Update the path, check the error, add a test. Fixes #14176. Change-Id: I203c40afe1448875581415d5e42c29f09b14545d Reviewed-on: https://go-review.googlesource.com/19180 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Fixes #14201. Change-Id: Ib61f8c00cae72463f59b90ae199fbdc1e7422a79 Reviewed-on: https://go-review.googlesource.com/19174 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Rob Pike authored
Fixes #14202 Change-Id: Ia6dccecb1b9b3f6c0838c99090e6ddf1ad43303c Reviewed-on: https://go-review.googlesource.com/19175 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
- 02 Feb, 2016 8 commits
-
-
Russ Cox authored
Fixes #14171. Change-Id: Ie75c1cfd88801618308d472bc04e7fc648c95e0c Reviewed-on: https://go-review.googlesource.com/19150Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates #13841 Change-Id: I121bce054e2756c820c76444e51357f474b7f3d6 Reviewed-on: https://go-review.googlesource.com/19161Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
RFC Errata 4522 (http://www.rfc-editor.org/errata_search.php?eid=4522) notes that RFC 2616 had a typo in a list of headers that the httputil.ReverseProxy code copied. Fix the typo in our code. Fixes #14174 Change-Id: Ifc8f18fd58a6508a02a23e54ff3c473f03e521d3 Reviewed-on: https://go-review.googlesource.com/19133Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Fixes #14195 Change-Id: I245b3ca3fd7d1a76aa95f2e058f8432ba5ce31ee Reviewed-on: https://go-review.googlesource.com/19160 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
This corrects a regression from Go 1.5 introduced by CL 18317. Fixes #14185. Change-Id: Ic3215714846d9f28809cd04e3eb3664b599244f4 Reviewed-on: https://go-review.googlesource.com/19151Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Tested manually with "go test -run TestGetSubmodules". Fixes #14194. Change-Id: I4f563b2b8a38f3040d7631f74a7908ab65e0860b Reviewed-on: https://go-review.googlesource.com/19154Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Failed at https://storage.googleapis.com/go-build-log/9875de36/nacl-amd64p32_931ba6cf.log Change-Id: I2bc204ed58da543ee2534b69c29c8e8485d54683 Reviewed-on: https://go-review.googlesource.com/19155 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently it's possible for the scheduler to deadlock with the right confluence of locked Gs, assists, and scheduling of background mark workers. Broadly, this happens because handoffp is stricter than findrunnable, and if the only work for a P is GC work, handoffp will put the P into idle, rather than starting an M to execute that P. One way this can happen is as follows: 0. There is only one user G, which we'll call G 1. There is more than one P, but they're all idle except the one running G 1. 1. G 1 locks itself to an M using runtime.LockOSThread. 2. GC starts up and enters mark 1. 3. G 1 performs a GC assist, which completes mark 1 without being fully satisfied. Completing mark 1 causes all background mark workers to park. And since the assist isn't fully satisfied, it parks as well, waiting for a background mark worker to satisfy its remaining assist debt. 4. The assist park enters the scheduler. Since G 1 is locked to the M, the scheduler releases the P and calls handoffp to hand the P to another M. 5. handoffp checks the local and global run queues, which are empty, and sees that there are idle Ps, so rather than start an M, it puts the P into idle. At this point, all of the Gs are waiting and all of the Ps are idle. In particular, none of the GC workers are running, so no mark work gets done and the assist on the main G is never satisfied, so the whole process soft locks up. Fix this by making handoffp start an M if there is GC work. This reintroduces a key invariant: that in any situation where findrunnable would return a G to run on a P, handoffp for that P will start an M to run work on that P. Fixes #13645. Tested by running 2,689 iterations of `go tool dist test -no-rebuild runtime:cpu124` across 10 linux-amd64-noopt VMs with no failures. Without this change, the failure rate was somewhere around 1%. Performance change is negligible. name old time/op new time/op delta XBenchGarbage-12 2.48ms ± 2% 2.48ms ± 1% -0.24% (p=0.000 n=92+93) name old time/op new time/op delta BinaryTree17-12 2.86s ± 2% 2.87s ± 2% ~ (p=0.667 n=19+20) Fannkuch11-12 2.52s ± 1% 2.47s ± 1% -2.05% (p=0.000 n=18+20) FmtFprintfEmpty-12 51.7ns ± 1% 51.5ns ± 3% ~ (p=0.931 n=16+20) FmtFprintfString-12 170ns ± 1% 168ns ± 1% -0.65% (p=0.000 n=19+19) FmtFprintfInt-12 160ns ± 0% 160ns ± 0% +0.18% (p=0.033 n=17+19) FmtFprintfIntInt-12 265ns ± 1% 273ns ± 1% +2.98% (p=0.000 n=17+19) FmtFprintfPrefixedInt-12 235ns ± 1% 239ns ± 1% +1.99% (p=0.000 n=16+19) FmtFprintfFloat-12 315ns ± 0% 315ns ± 1% ~ (p=0.250 n=17+19) FmtManyArgs-12 1.04µs ± 1% 1.05µs ± 0% +0.87% (p=0.000 n=17+19) GobDecode-12 7.93ms ± 0% 7.85ms ± 1% -1.03% (p=0.000 n=16+18) GobEncode-12 6.62ms ± 1% 6.58ms ± 1% -0.60% (p=0.000 n=18+19) Gzip-12 322ms ± 1% 320ms ± 1% -0.46% (p=0.009 n=20+20) Gunzip-12 42.5ms ± 1% 42.5ms ± 0% ~ (p=0.751 n=19+19) HTTPClientServer-12 69.7µs ± 1% 70.0µs ± 2% ~ (p=0.056 n=19+19) JSONEncode-12 16.9ms ± 1% 16.7ms ± 1% -1.13% (p=0.000 n=19+19) JSONDecode-12 61.5ms ± 1% 61.3ms ± 1% -0.35% (p=0.001 n=20+17) Mandelbrot200-12 3.94ms ± 0% 3.91ms ± 0% -0.67% (p=0.000 n=20+18) GoParse-12 3.71ms ± 1% 3.70ms ± 1% ~ (p=0.244 n=17+19) RegexpMatchEasy0_32-12 101ns ± 1% 102ns ± 2% +0.54% (p=0.037 n=19+20) RegexpMatchEasy0_1K-12 349ns ± 0% 350ns ± 0% +0.33% (p=0.000 n=17+18) RegexpMatchEasy1_32-12 84.5ns ± 2% 84.2ns ± 1% -0.43% (p=0.048 n=19+20) RegexpMatchEasy1_1K-12 510ns ± 1% 513ns ± 2% +0.58% (p=0.002 n=18+20) RegexpMatchMedium_32-12 132ns ± 1% 134ns ± 1% +0.95% (p=0.000 n=20+20) RegexpMatchMedium_1K-12 40.1µs ± 1% 39.6µs ± 1% -1.39% (p=0.000 n=20+20) RegexpMatchHard_32-12 2.08µs ± 0% 2.06µs ± 1% -0.95% (p=0.000 n=18+18) RegexpMatchHard_1K-12 62.2µs ± 1% 61.9µs ± 1% -0.42% (p=0.001 n=19+20) Revcomp-12 537ms ± 0% 536ms ± 0% ~ (p=0.076 n=20+20) Template-12 71.3ms ± 1% 69.3ms ± 1% -2.75% (p=0.000 n=20+20) TimeParse-12 361ns ± 0% 360ns ± 1% ~ (p=0.056 n=19+19) TimeFormat-12 353ns ± 0% 352ns ± 0% -0.23% (p=0.000 n=17+18) [Geo mean] 62.6µs 62.5µs -0.17% Change-Id: I0fbbbe4d7d99653ba5600ffb4394fa03558bc4e9 Reviewed-on: https://go-review.googlesource.com/19107Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 01 Feb, 2016 3 commits
-
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev 644ffc for three CLs since the last update: http2: don't add *Response to activeRes in Transport on Headers.END_STREAM https://golang.org/cl/19134 http2: add mechanism to send undeclared Trailers mid handler https://golang.org/cl/19131 http2: remove unused variable https://golang.org/cl/18936 The first in the list above is the main fix that's necessary. The other are two are in the git history but along for the cmd/bundle ride. The middle CL is well-tested, small (mostly comments), non-tricky, and almost never seen (since nobody really uses Trailers). The final CL is just deleting an unused global variable. Fixes #14084 again (with more tests) Change-Id: Iac51350acee9c51d32bf7779d57e9d5a5482b928 Reviewed-on: https://go-review.googlesource.com/19135 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Ian Lance Taylor authored
Tested by hand with a runtime/cgo modified to return an mmap failure after 10 calls. This is an interim patch. For 1.7 we should fix mmap properly to avoid using the same value as both a pointer and an errno value. Fixes #14149. Change-Id: I8f2bbd47d711e283001ba73296f1c34a26c59241 Reviewed-on: https://go-review.googlesource.com/19084 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Robert Griesemer authored
Fixes #14164. Change-Id: Ib1d1d29674c99cf88e0ae12724823a31f5dbb95c Reviewed-on: https://go-review.googlesource.com/19087 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
- 29 Jan, 2016 6 commits
-
-
Brad Fitzpatrick authored
Fixes #14146 Change-Id: I892ca4ccdc1ba785750e1eae800852dc5825156c Reviewed-on: https://go-review.googlesource.com/19093Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
This CL expands symlinks only when an error would be reported otherwise. Since the expansions are only on error paths, anything that worked yesterday should still work after this CL. This CL fixes a regression from Go 1.5 in "go run", or else we'd probably postpone it. Changing only the error paths is meant as a way to reduce the risk of making this change so late in the release cycle, but it may actually be the right strategy for symlinks in general. Fixes #14054. Change-Id: I42ed1276f67a0c395297a62bcec7d36c14c06404 Reviewed-on: https://go-review.googlesource.com/19102 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Given, say, var f *os.File, a new vet check in CL 14122 diagnoses: fmt.Printf("%s\n", f.Name) fmt.Println(f.Name) but not fmt.Printf("%v\n", f.Name) In all three cases the error is that the argument should be f.Name(). Diagnosing Println but not Printf %v seems oddly inconsistent, so I changed %v to have the check too. In fact, all verbs now have the check except %p and %T. Fixes Dave Cheney's confusion when trying to write an example of the new vet check advertised in the Go 1.6 release notes. Change-Id: I92fa6a7a1d5d9339a6a59ae4e587a254e633f500 Reviewed-on: https://go-review.googlesource.com/19101 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Mikio Hara authored
Fixes #14124. Change-Id: I9a694c402e613d27701e7e41640af357c373edea Reviewed-on: https://go-review.googlesource.com/18959Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Andrew Gerrand authored
Fixes #14143 Change-Id: I2d77e55bc0b6bb42e11de291e0ddb5ad5d620646 Reviewed-on: https://go-review.googlesource.com/19110Reviewed-by: Russ Cox <rsc@golang.org>
-
Rahul Chaudhry authored
Change-Id: Ib669d5241372326a46361ee096570e960b7a957f Reviewed-on: https://go-review.googlesource.com/19082Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 28 Jan, 2016 2 commits
-
-
Brad Fitzpatrick authored
From twitter bug report: https://twitter.com/ox/status/692737249411207168 Change-Id: Ic5f4eeb00d705217542db558edc25e206f6b640d Reviewed-on: https://go-review.googlesource.com/19050Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
We might be forwarding to a C signal handler. C code expects the stack to be aligned. Should fix darwin/386 build: the testcarchive tests were hanging as the program got an endless series of SIGSEGV signals. Change-Id: Ia02485d3736a3c40e12259f02d25f842cf8e4d29 Reviewed-on: https://go-review.googlesource.com/19025 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 27 Jan, 2016 9 commits
-
-
Ian Lance Taylor authored
It's awkward to get a string value in cgoCheckArg, but SWIG testing revealed that it is possible. The new handling of extra files in the ptr.go test emulates what SWIG does with an exported function that returns a string. Change-Id: I453717f867b8a49499576c28550e7c93053a0cf8 Reviewed-on: https://go-review.googlesource.com/19020 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
It doesn't work there ("out of memory") and doesn't really matter. Fixes build (now that we enable cgo on the darwin/386 builder.) Change-Id: I1d91e51ecb88c54eae39ac9a76f2c0b4e45263b0 Reviewed-on: https://go-review.googlesource.com/19004 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #14107. Change-Id: Icd9463b1a77b139c7ebc2d8732482d704ea332d0 Reviewed-on: https://go-review.googlesource.com/19002Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Followup to CL 19001. Change-Id: I7fa838b1ee8df53229e9dd29a231c2f9b2aa3f69 Reviewed-on: https://go-review.googlesource.com/19003Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
It's causing the darwin-386 builder to fail with: --- FAIL: TestDynlink (0.07s) obj6_test.go:118: error exit status 3 output go tool: no such tool "asm" FAIL FAIL cmd/internal/obj/x86 0.073s So skip it for now. It's tested in enough other places. Change-Id: I9a98ad7b8be807005750112d892ac6c676c17dd5 Reviewed-on: https://go-review.googlesource.com/18989 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
This makes "CGO_ENABLED=0 go list runtime/cgo" work, which fixes the current cmd/go test failure. Change-Id: Ia55ce3ba1dbb09f618ae5f4c8547722670360f59 Reviewed-on: https://go-review.googlesource.com/19001 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dmitry Vyukov authored
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/18968Reviewed-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>
-
Richard Miller authored
CL 18964 included an extra patch (sorry, my first experience of git-codereview) which defined the conventional breakpoint instruction used by Plan 9 on arm, but also introduced a benign but unneeded call to runtime.emptyfunc. This CL removes the redundant call again. This completes the series of CLs which add support for Plan 9 on arm. Change-Id: Id293cfd40557c9d79b4b6cb164ed7ed49295b178 Reviewed-on: https://go-review.googlesource.com/19010Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Also fix a few bad links. Change-Id: If04cdd312db24a827a3c958a9974c50ab148656c Reviewed-on: https://go-review.googlesource.com/18979Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-