- 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 21 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>
-
Russ Cox authored
The vendored copy of golang.org/x/net/http/hpack was being treated as not standard, which in turn was making it not subject to the mtime exception for rebuilding the standard library in a release, which in turn was making net/http look out of date. One fix and three tests: - Fix the definition of standard. - Test that everything in $GOROOT/src/ is standard during 'go test cmd/go'. (In general there can be non-standard things in $GOROOT/src/, but this test implies that you can do that or you can run 'go test cmd/go', but not both. That's fine.) - Test that 'go list std cmd' shows our vendored code. - Enforce that no standard package can depend on a non-standard one. Also fix a few error printing nits. Fixes #13713. Change-Id: I1f943f1c354174c199e9b52075c11ee44198e81b Reviewed-on: https://go-review.googlesource.com/18978Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Change-Id: I595379d2f02b0a43735f0375758e4997ce3b64a7 Reviewed-on: https://go-review.googlesource.com/18986 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Change-Id: Ibba7fccba9617612e026bd0a208eb12918de465a Reviewed-on: https://go-review.googlesource.com/18985Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Martin Lenord pointed out that bad patterns have emerged in online examples of how to use ServeFile, where people pass r.URL.Path[1:] to ServeFile. This is unsafe. Document that it's unsafe, and add some protections. Fixes #14110 Change-Id: Ifeaa15534b2b3e46d3a8137be66748afa8fcd634 Reviewed-on: https://go-review.googlesource.com/18939Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Richard Miller authored
Add magic word for Plan 9 ARM object header to objectMagic table. Change-Id: I21eb8845a2ee2e8cdddc0849eedf43481aee9cde Reviewed-on: https://go-review.googlesource.com/18963Reviewed-by: Russ Cox <rsc@golang.org>
-
Richard Miller authored
Fields in Plan 9 object headers are big-endian, on all architectures. Change-Id: If95ad29750b776338178d660646568bf26a4abda Reviewed-on: https://go-review.googlesource.com/18964Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Also document the special behavior of Alignof(s.f), and mention the correspondence between Alignof and reflect.Type.{Align,FieldAlign}. Change-Id: I6f81047a04c86887f1b1164473225616cae45a26 Reviewed-on: https://go-review.googlesource.com/18949 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Fixes #9157 Change-Id: Iadf305a172a0ec53ae91e1b2db3f3351691a48ff Reviewed-on: https://go-review.googlesource.com/18935Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
It's possible for arena_start+MaxArena32 to wrap. We do the right thing in the bounds check but not in the print. For #13992 (to fix the print there, not the bug). Change-Id: I4df845d0c03f0f35461b128e4f6765d3ccb71c6d Reviewed-on: https://go-review.googlesource.com/18975 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
The previous CL is the real fix. This one is just insurance. Fixes #14046 again. Change-Id: I553349504bb1789e4b66c888dbe4034568918ad6 Reviewed-on: https://go-review.googlesource.com/18977Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
It was just completely broken if you gave it the number of records it asked for. Make it impossible for that particular inconsistency to happen again. Also make it exclude system goroutines, to match both NumGoroutine and Stack. Fixes #14046. Change-Id: Ic238c6b89934ba7b47cccd3440dd347ed11e4c3d Reviewed-on: https://go-review.googlesource.com/18976 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
For Go 1.7 we can remove all the code.google.com code (except maybe the shutdown warning). See #10193. Change-Id: I4b8182eb66494f0bf373b40ca5da6ae4738342be Reviewed-on: https://go-review.googlesource.com/18974Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-