- 10 Aug, 2015 1 commit
-
-
Dave Cheney authored
Fixes #12062 Updates #11961 The sRPC nameservice was removed in pepper 42. For Go 1.5 stipulate that NaCl requires pepper 41 only. Change-Id: Ic88ba342d41f673391efaa96fb581712fa10a0fd Reviewed-on: https://go-review.googlesource.com/13341Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 07 Aug, 2015 4 commits
-
-
Russ Cox authored
Changes the torture test in #12068 from failing about 1/10 times to not failing in almost 2,000 runs. This was only happening in -race mode because functions are bigger in -race mode, so a few of the helpers for heapBitsBulkBarrier were not being inlined, and they were not marked nosplit, so (only in -race mode) the write barrier was being preempted by GC, causing missed pointer updates. Filed issue #12069 for diagnosis of any other similar errors. Fixes #12068. Change-Id: Ic174d9b050ba278b18b08ab0d85a73c33bd5b175 Reviewed-on: https://go-review.googlesource.com/13364Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
Also, crash early on non-Linux SMP ARM systems when GOARM < 7; without the proper synchronization, SMP cannot work. Linux is okay because we call kernel-provided routines for synchronization and barriers, and the kernel takes care of providing the right routines for the current system. On non-Linux systems we are left to fend for ourselves. It is possible to use different synchronization on GOARM=6, but it's too late to do that in the Go 1.5 cycle. We don't believe there are any non-Linux SMP GOARM=6 systems anyway. Fixes #12067. Change-Id: I771a556e47893ed540ec2cd33d23c06720157ea3 Reviewed-on: https://go-review.googlesource.com/13363Reviewed-by: Austin Clements <austin@google.com>
-
Andrew Gerrand authored
Change-Id: I625c9df161da2febdca85741c75fc32d4bef420b Reviewed-on: https://go-review.googlesource.com/13344Reviewed-by: Rob Pike <r@golang.org>
-
Andrew Gerrand authored
Change-Id: I6bea045bb1cef15e6d9d3b4e6e6b4ae91f7bb941 Reviewed-on: https://go-review.googlesource.com/13345Reviewed-by: Rob Pike <r@golang.org>
-
- 06 Aug, 2015 8 commits
-
-
Russ Cox authored
Fixes #12060. Change-Id: Ie2fd10bedded1a4f4e0daa0c0c77ecd898480767 Reviewed-on: https://go-review.googlesource.com/13324Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
Currently, runtime.Goexit() calls goexit()—the goroutine exit stub—to terminate the goroutine. This *mostly* works, but can cause a "leftover stack barriers" panic if the following happens: 1. Goroutine A has a reasonably large stack. 2. The garbage collector scan phase runs and installs stack barriers in A's stack. The top-most stack barrier happens to fall at address X. 3. Goroutine A unwinds the stack far enough to be a candidate for stack shrinking, but not past X. 4. Goroutine A calls runtime.Goexit(), which calls goexit(), which calls goexit1(). 5. The garbage collector enters mark termination. 6. Goroutine A is preempted right at the prologue of goexit1() and performs a stack shrink, which calls gentraceback. gentraceback stops as soon as it sees goexit on the stack, which is only two frames up at this point, even though there may really be many frames above it. More to the point, the stack barrier at X is above the goexit frame, so gentraceback never sees that stack barrier. At the end of gentraceback, it checks that it saw all of the stack barriers and panics because it didn't see the one at X. The fix is simple: call goexit1, which actually implements the process of exiting a goroutine, rather than goexit, the exit stub. To make sure this doesn't happen again in the future, we also add an argument to the stub prototype of goexit so you really, really have to want to call it in order to call it. We were able to reliably reproduce the above sequence with a fair amount of awful code inserted at the right places in the runtime, but chose to change the goexit prototype to ensure this wouldn't happen again rather than pollute the runtime with ugly testing code. Change-Id: Ifb6fb53087e09a252baddadc36eebf954468f2a8 Reviewed-on: https://go-review.googlesource.com/13323Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
This makes TestTraceStressStartStop much less flaky. Running under stress, it changes the failure rate from above 1/100 to under 1/50000. That very unlikely failure happens when an unexpected GoSysExit is written. Not sure how that happens yet, but it is much less important. Fixes #11953. Change-Id: I034671936334b4f3ab733614ef239aa121d20247 Reviewed-on: https://go-review.googlesource.com/13321Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Joe Shaw authored
Fixes #12053 Change-Id: Icd883b4f1ac944a8ec718c79770a8e3fc6542e3a Reviewed-on: https://go-review.googlesource.com/13259Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
The old code was only allowing the chars we choose not to escape. We sometimes prefer to escape chars that do not strictly need it. Allowing those to be used in RawPath lets people override that preference, which is in fact the whole point of RawPath (new in Go 1.5). While we are here, also allow [ ] in RawPath. This is not strictly spec-compliant, but it is what modern browers do and what at least some people expect, and the [ ] do not cause any ambiguity (the usual reason they would be escaped, as they are part of the RFC gen-delims class). The argument for allowing them now instead of waiting until Go 1.6 is that this way RawPath has one fixed meaning at the time it is introduced, that we should not need to change or expand. Fixes #5684. Change-Id: If9c82a18f522d7ee1d10310a22821ada9286ee5c Reviewed-on: https://go-review.googlesource.com/13258Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
The code in question was added as part of allowing zone identifiers in IPv6 literals like http://[ipv6%zone]:port/foo, in golang.org/cl/2431. The old condition makes no sense. It refers to §3.2.1, which is the wrong section of the RFC, it excludes all the sub-delims, which §3.2.2 (the right section) makes clear are valid, and it allows ':', which is not actually valid, without an explanation as to why (because we keep :port in the Host field of the URL struct). The new condition allows all the sub-delims, as specified in RFC 3986, plus the additional characters [ ] : seen in IP address literals and :port suffixes, which we also keep in the Host field. This allows mysql://a,b,c/path to continue to parse, as it did in Go 1.4 and earlier. This CL does not break any existing tests, suggesting the over-conservative behavior was not intended and perhaps not realized. It is especially important not to over-escape the host field, because Go does not unescape the host field during parsing: it rejects any host field containing % characters. Fixes #12036. Change-Id: Iccbe4985957b3dc58b6dfb5dcb5b63a51a6feefb Reviewed-on: https://go-review.googlesource.com/13254Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
-
Mikio Hara authored
Change-Id: Ic61fd38e7d2e0821c6adcaa210199a7dae8849a7 Reviewed-on: https://go-review.googlesource.com/13281Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Russ Cox authored
Go 1.4 and earlier accepted mysql://x@y(z:123)/foo and I don't see any compelling reason to break that. The CL during Go 1.5 that broke this syntax was trying to fix #11208 and was probably too aggressive. I added a test case for #11208 to make sure that stays fixed. Relaxing the check did not re-break #11208 nor did it cause any existing test to fail. I added a test for the mysql://x@y(z:123)/foo syntax being preserved. Fixes #12023. Change-Id: I659d39f18c85111697732ad24b757169d69284fc Reviewed-on: https://go-review.googlesource.com/13253Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
-
- 05 Aug, 2015 22 commits
-
-
Andrew Gerrand authored
Fixes #10639 Change-Id: I0aa3bcbf656e23e6a110041439f6052057074b88 Reviewed-on: https://go-review.googlesource.com/13270Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #11977. Fixes #11988. Change-Id: I9f80006946d3752ee6d644ee51f2decfeaca1ff6 Reviewed-on: https://go-review.googlesource.com/13230Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Robert Griesemer authored
For #11669, #11540, #11945, #11946, #11947. Change-Id: Ifb0053c498cee9f3473c396f9338d82bd856c110 Reviewed-on: https://go-review.googlesource.com/12860Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Strengthening VerifyHostname exposed the fact that for resumed connections, ConnectionState().VerifiedChains was not being saved and restored during the ClientSessionCache operations. Do that. This change just saves the verified chains in the client's session cache. It does not re-verify the certificates when resuming a connection. There are arguments both ways about this: we want fast, light-weight resumption connections (thus suggesting that we shouldn't verify) but it could also be a little surprising that, if the verification config is changed, that would be ignored if the same session cache is used. On the server side we do re-verify client-auth certificates, but the situation is a little different there. The client session cache is an object in memory that's reset each time the process restarts. But the server's session cache is a conceptual object, held by the clients, so can persist across server restarts. Thus the chance of a change in verification config being surprisingly ignored is much higher in the server case. Fixes #12024. Change-Id: I3081029623322ce3d9f4f3819659fdd9a381db16 Reviewed-on: https://go-review.googlesource.com/13164Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Russ Cox authored
Otherwise clean.bash cleans $GOROOT, which might be something else entirely. Fixes #12003. Change-Id: I2ad5369017dde6db25f0c0514bc27c33d0a8bf54 Reviewed-on: https://go-review.googlesource.com/13251Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Jed Denlea authored
Prior to this change, broken trailers would be handled by body.Read, and an error would be returned to its caller (likely a Handler), but that error would go completely unnoticed by the rest of the server flow allowing a broken connection to be reused. This is a possible request smuggling vector. Fixes #12027. Change-Id: I077eb0b8dff35c5d5534ee5f6386127c9954bd58 Reviewed-on: https://go-review.googlesource.com/13148Reviewed-by: Russ Cox <rsc@golang.org>
-
Adam Langley authored
This change alters the certificate used in many tests so that it's no longer self-signed. This allows some tests to exercise the standard certificate verification paths in the future. Change-Id: I9c3fcd6847eed8269ff3b86d9b6966406bf0642d Reviewed-on: https://go-review.googlesource.com/13244Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Russ Cox authored
Change-Id: Id1e30d70d6891ef12110f8e7832b94eeac9e2fa9 Reviewed-on: https://go-review.googlesource.com/13250Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
88e945fd introduced a non-speculative double check of the heap trigger before actually starting a concurrent GC. This was necessary to fix a race for heap-triggered GC, but broke sysmon-triggered periodic GC, since the heap check will of course fail for periodically triggered GC. Fix this by telling startGC whether or not this GC was triggered by heap size or a timer and only doing the heap size double check for GCs triggered by heap size. Fixes #12026. Change-Id: I7c3f6ec364545c36d619f2b4b3bf3b758e3bcbd6 Reviewed-on: https://go-review.googlesource.com/13168Reviewed-by: Russ Cox <rsc@golang.org>
-
Robert Griesemer authored
First step towards cleaning up the operator section - no language changes. Specifically: - Grouped arithmetic operations by types (integer, floating-point, string), with corresponding h4 headings. - Changed Operator precedence title from h3 to h4. - Moved Integer Overflow section after integer operations and changed its title from h3 to h4. This puts things that belong together closer. No heading id's were lost (in case of references from outside the spec). Change-Id: I6b349ba8d86a6ae29b596beb297cc45c81e69399 Reviewed-on: https://go-review.googlesource.com/13143Reviewed-by: Rob Pike <r@golang.org>
-
Robert Griesemer authored
Inconsistency identified by Anmol Sethi (anmol@aubble.com). Fixes #10341. Change-Id: I1a1f5b22aad29b56280f81026feaa37a61b3e0a9 Reviewed-on: https://go-review.googlesource.com/13132Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Robert Griesemer authored
Fixes #9837. Change-Id: Ia513c7e5db221eee8e3ab0affa6d3688d2099fd9 Reviewed-on: https://go-review.googlesource.com/13130Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Robert Griesemer authored
Fixes #10514. Change-Id: Iae95a304d3ebb1ed82567aa234e05dc434db984f Reviewed-on: https://go-review.googlesource.com/13098Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Missed in CL 13074. Change-Id: Ic0600341abbc423cd8d7b2201bf50e3b0bf398a7 Reviewed-on: https://go-review.googlesource.com/13167Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Now that it works we need to turn it back on. Fixes #10119. Change-Id: I9c62d3026f7bb62c49a601ad73f33bf655372915 Reviewed-on: https://go-review.googlesource.com/13162Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
It is just far too slow. I have a CL for Go 1.6 that makes many of these into internal tests. That will improve the coverage. It does not matter much, because basically none of the go command tests are architecture dependent, so the other builders will catch any problems. Fixes freebsd-arm builder. Change-Id: I8b2f6ac2cc1e7657019f7731c6662dc43e20bfb5 Reviewed-on: https://go-review.googlesource.com/13166Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
This works after golang.org/cl/13120 is running on the coordinator (maybe it already is). Change-Id: I4053d8e2f32fafd47b927203a6f66d5858e23376 Reviewed-on: https://go-review.googlesource.com/13165Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Austin Clements authored
Change-Id: I4e8c20284255e0e17b6fb72475d2d37f49994788 Reviewed-on: https://go-review.googlesource.com/13113Reviewed-by: Rob Pike <r@golang.org>
-
Dmitry Vyukov authored
Tracing functionality was moved from runtime/pprof to runtime/trace. Change-Id: I694e0f209d043c7ffecb113f1825175bf963dde3 Reviewed-on: https://go-review.googlesource.com/13074Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
This is what is causing freebsd/arm to crash mysteriously when using cgo. The bug was introduced in golang.org/cl/4030, which moved this code out of rt0_go and into its own function. The ARM ABI says that calls must be made with the stack pointer at an 8-byte boundary, but only FreeBSD seems to crash when this is violated. Fixes #10119. Change-Id: Ibdbe76b2c7b80943ab66b8abbb38b47acb70b1e5 Reviewed-on: https://go-review.googlesource.com/13161Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net>
-
Andrew Gerrand authored
This change allows the download page to redirect the user to /doc/install?download=filename so the user can see installation instructions specific to the file they are downloading. This change also expands the "Test your Go installation" section to instruct the user to create a workspace, hopefully leading to less confusion down the line. It also changes the front page download link to go directly to the downloads page, which will in turn take them to the installation instructions (the original destination). This is related to this change to the tools repo: https://golang.org/cl/13180 Change-Id: I658327bdb93ad228fb1846e389b281b15da91b1d Reviewed-on: https://go-review.googlesource.com/13151Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Andrew Gerrand authored
Fixes #11995 Change-Id: I9e2901d77ebde705f59822e7d4a8163cbacffcd7 Reviewed-on: https://go-review.googlesource.com/13150Reviewed-by: Rob Pike <r@golang.org>
-
- 04 Aug, 2015 5 commits
-
-
Robert Griesemer authored
Fixes #12017. Change-Id: I3dfcf9d0b62cae02eca1973383f0aad286a6ef4d Reviewed-on: https://go-review.googlesource.com/13136Reviewed-by: Keith Randall <khr@golang.org>
-
Austin Clements authored
Change-Id: I66f7937b22bb6e05c3f2f0f2a057151020ad9699 Reviewed-on: https://go-review.googlesource.com/13049Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
When commit 510fd135 enabled assists during the scan phase, it failed to also update the code in the GC controller that computed the assist CPU utilization and adjusted the trigger based on it. Fix that code so it uses the start of the scan phase as the wall-clock time when assists were enabled rather than the start of the mark phase. Change-Id: I05013734b4448c3e2c730dc7b0b5ee28c86ed8cf Reviewed-on: https://go-review.googlesource.com/13048Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
At the start of a GC cycle, the garbage collector computes the assist ratio based on the total scannable heap size. This was intended to be conservative; after all, this assumes the entire heap may be reachable and hence needs to be scanned. But it only assumes that the *current* entire heap may be reachable. It fails to account for heap allocated during the GC cycle. If the trigger ratio is very low (near zero), and most of the heap is reachable when GC starts (which is likely if the trigger ratio is near zero), then it's possible for the mutator to create new, reachable heap fast enough that the assists won't keep up based on the assist ratio computed at the beginning of the cycle. As a result, the heap can grow beyond the heap goal (by hundreds of megs in stress tests like in issue #11911). We already have some vestigial logic for dealing with situations like this; it just doesn't run often enough. Currently, every 10 ms during the GC cycle, the GC revises the assist ratio. This was put in before we switched to a conservative assist ratio (when we really were using estimates of scannable heap), and it turns out to be exactly what we need now. However, every 10 ms is far too infrequent for a rapidly allocating mutator. This commit reuses this logic, but replaces the 10 ms timer with revising the assist ratio every time the heap is locked, which coincides precisely with when the statistics used to compute the assist ratio are updated. Fixes #11911. Change-Id: I377b231ab064946228378fa10422a46d1b50f4c5 Reviewed-on: https://go-review.googlesource.com/13047Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Austin Clements authored
This was useful in debugging the mutator assist behavior for #11911, and it fits with the other gcpacertrace output. Change-Id: I1e25590bb4098223a160de796578bd11086309c7 Reviewed-on: https://go-review.googlesource.com/13046Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-