summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [release-branch.go1.7] go1.7.6go1.7.6release-branch.go1.7Chris Broadfoot2017-05-231-1/+1
| | | | | | Change-Id: I6361937bb2684c6b64edafc19d7d175210638063 Reviewed-on: https://go-review.googlesource.com/43992 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] crypto/elliptic: fix carry bug in x86-64 P-256 ↵Adam Langley2017-05-232-5/+41
| | | | | | | | | | | | | | | | | | implementation. Patch from Vlad Krasnov and confirmed to be under CLA. Fixes #20040. Change-Id: Ieb8436c4dcb6669a1620f1e0d257efd047b1b87c Reviewed-on: https://go-review.googlesource.com/41070 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 9294fa2749ffee7edbbb817a0ef9fe633136fa9c) Reviewed-on: https://go-review.googlesource.com/43773 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] go1.7.5go1.7.5Chris Broadfoot2017-01-261-1/+1
| | | | | | | Change-Id: I09b5f6f3c79ec691f6d2fd28551dc06d79105c42 Reviewed-on: https://go-review.googlesource.com/35834 Run-TryBot: Chris Broadfoot <cbro@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] doc: document go1.7.5Chris Broadfoot2017-01-261-0/+7
| | | | | | | | | Change-Id: Ic8d4e971edebba9412f2e7c3d3c29f296c4977ff Reviewed-on: https://go-review.googlesource.com/35833 Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/35835 Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] crypto/x509: speed up and deflake non-cgo Darwin root ↵Brad Fitzpatrick2017-01-252-60/+180
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cert discovery Backporting Go 1.8's fix to #18203 Fixes #18688 --- Piping into security verify-cert only worked on macOS Sierra, and was flaky for unknown reasons. Users reported that the number of trusted root certs stopped randomly jumping around once they switched to using verify-cert against files on disk instead of /dev/stdin. But even using "security verify-cert" on 150-200 certs took too long. It took 3.5 seconds on my machine. More than 4 goroutines hitting verify-cert didn't help much, and soon started to hurt instead. New strategy, from comments in the code: // 1. Run "security trust-settings-export" and "security // trust-settings-export -d" to discover the set of certs with some // user-tweaked trusy policy. We're too lazy to parse the XML (at // least at this stage of Go 1.8) to understand what the trust // policy actually is. We just learn that there is _some_ policy. // // 2. Run "security find-certificate" to dump the list of system root // CAs in PEM format. // // 3. For each dumped cert, conditionally verify it with "security // verify-cert" if that cert was in the set discovered in Step 1. // Without the Step 1 optimization, running "security verify-cert" // 150-200 times takes 3.5 seconds. With the optimization, the // whole process takes about 180 milliseconds with 1 untrusted root // CA. (Compared to 110ms in the cgo path) Change-Id: I79737d9f2cb9b020ba297a326d4d31d68c7e9fee Reviewed-on: https://go-review.googlesource.com/35634 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
* [release-branch.go1.7] runtime: fix getArgInfo for deferred reflection callsAustin Clements2017-01-253-7/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #18333 (backport) getArgInfo for reflect.makeFuncStub and reflect.methodValueCall is necessarily special. These have dynamically determined argument maps that are stored in their context (that is, their *funcval). These functions are written to store this context at 0(SP) when called, and getArgInfo retrieves it from there. This technique works if getArgInfo is passed an active call frame for one of these functions. However, getArgInfo is also used in tracebackdefers, where the "call" is not a true call with an active stack frame, but a deferred call. In this situation, getArgInfo currently crashes because tracebackdefers passes a frame with sp set to 0. However, the entire approach used by getArgInfo is flawed in this situation because the wrapper has not actually executed, and hence hasn't saved this metadata to any stack frame. In the defer case, we know the *funcval from the _defer itself, so we can fix this by teaching getArgInfo to use the *funcval context directly when its available, and otherwise get it from the active call frame. While we're here, this commit simplifies getArgInfo a bit by making it play more nicely with the type system. Rather than decoding the *reflect.methodValue that is the wrapper's context as a *[2]uintptr, just write out a copy of the reflect.methodValue type in the runtime. Fixes #16331. Fixes #17471. Change-Id: I81db4d985179b4a81c68c490cceeccbfc675456a Reviewed-on: https://go-review.googlesource.com/31138 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-on: https://go-review.googlesource.com/35638 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
* [release-branch.go1.7] runtime: force workers out before checking mark rootsAustin Clements2017-01-251-2/+10
| | | | | | | | | | | | | | | | | | | | | | | Fixes #18700 (backport) Currently we check that all roots are marked as soon as gcMarkDone decides to transition from mark 1 to mark 2. However, issue #16083 indicates that there may be a race where we try to complete mark 1 while a worker is still scanning a stack, causing the root mark check to fail. We don't yet understand this race, but as a simple mitigation, move the root check to after gcMarkDone performs a ragged barrier, which will force any remaining workers to finish their current job. Updates #16083. This may "fix" it, but it would be better to understand and fix the underlying race. Change-Id: I1af9ce67bd87ade7bc2a067295d79c28cd11abd2 Reviewed-on: https://go-review.googlesource.com/35678 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] runtime: fix corruption crash/race between select and ↵Russ Cox2017-01-251-4/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stack growth Fixes #18708 (backport) To implement the blocking of a select, a goroutine builds a list of offers to communicate (pseudo-g's, aka sudog), one for each case, queues them on the corresponding channels, and waits for another goroutine to complete one of those cases and wake it up. Obviously it is not OK for two other goroutines to complete multiple cases and both wake the goroutine blocked in select. To make sure that only one branch of the select is chosen, all the sudogs contain a pointer to a shared (single) 'done uint32', which is atomically cas'ed by any interested goroutines. The goroutine that wins the cas race gets to wake up the select. A complication is that 'done uint32' is stored on the stack of the goroutine running the select, and that stack can move during the select due to stack growth or stack shrinking. The relevant ordering to block and unblock in select is: 1. Lock all channels. 2. Create list of sudogs and queue sudogs on all channels. 3. Switch to system stack, mark goroutine as asleep, unlock all channels. 4. Sleep until woken. 5. Wake up on goroutine stack. 6. Lock all channels. 7. Dequeue sudogs from all channels. 8. Free list of sudogs. 9. Unlock all channels. There are two kinds of stack moves: stack growth and stack shrinking. Stack growth happens while the original goroutine is running. Stack shrinking happens asynchronously, during garbage collection. While a channel listing a sudog is locked by select in this process, no other goroutine can attempt to complete communication on that channel, because that other goroutine doesn't hold the lock and can't find the sudog. If the stack moves while all the channel locks are held or when the sudogs are not yet or no longer queued in the channels, no problem, because no goroutine can get to the sudogs and therefore to selectdone. We only need to worry about the stack (and 'done uint32') moving with the sudogs queued in unlocked channels. Stack shrinking can happen any time the goroutine is stopped. That code already acquires all the channel locks before doing the stack move, so it avoids this problem. Stack growth can happen essentially any time the original goroutine is running on its own stack (not the system stack). In the first half of the select, all the channels are locked before any sudogs are queued, and the channels are not unlocked until the goroutine has stopped executing on its own stack and is asleep, so that part is OK. In the second half of the select, the goroutine wakes up on its own goroutine stack and immediately locks all channels. But the actual call to lock might grow the stack, before acquiring any locks. In that case, the stack is moving with the sudogs queued in unlocked channels. Not good. One goroutine has already won a cas on the old stack (that goroutine woke up the selecting goroutine, moving it out of step 4), and the fact that done = 1 now should prevent any other goroutines from completing any other select cases. During the stack move, however, sudog.selectdone is moved from pointing to the old done variable on the old stack to a new memory location on the new stack. Another goroutine might observe the moved pointer before the new memory location has been initialized. If the new memory word happens to be zero, that goroutine might win a cas on the new location, thinking it can now complete the select (again). It will then complete a second communication (reading from or writing to the goroutine stack incorrectly) and then attempt to wake up the selecting goroutine, which is already awake. The scribbling over the goroutine stack unexpectedly is already bad, but likely to go unnoticed, at least immediately. As for the second wakeup, there are a variety of ways it might play out. * The goroutine might not be asleep. That will produce a runtime crash (throw) like in #17007: runtime: gp: gp=0xc0422dcb60, goid=2299, gp->atomicstatus=8 runtime: g: g=0xa5cfe0, goid=0, g->atomicstatus=0 fatal error: bad g->status in ready Here, atomicstatus=8 is copystack; the second, incorrect wakeup is observing that the selecting goroutine is in state "Gcopystack" instead of "Gwaiting". * The goroutine might be sleeping in a send on a nil chan. If it wakes up, it will crash with 'fatal error: unreachable'. * The goroutine might be sleeping in a send on a non-nil chan. If it wakes up, it will crash with 'fatal error: chansend: spurious wakeup'. * The goroutine might be sleeping in a receive on a nil chan. If it wakes up, it will crash with 'fatal error: unreachable'. * The goroutine might be sleeping in a receive on a non-nil chan. If it wakes up, it will silently (incorrectly!) continue as if it received a zero value from a closed channel, leaving a sudog queued on the channel pointing at that zero vaue on the goroutine's stack; that space will be reused as the goroutine executes, and when some other goroutine finally completes the receive, it will do a stray write into the goroutine's stack memory, which may cause problems. Then it will attempt the real wakeup of the goroutine, leading recursively to any of the cases in this list. * The goroutine might have been running a select in a finalizer (I hope not!) and might now be sleeping waiting for more things to finalize. If it wakes up, as long as it goes back to sleep quickly (before the real GC code tries to wake it), the spurious wakeup does no harm (but the stack was still scribbled on). * The goroutine might be sleeping in gcParkAssist. If it wakes up, that will let the goroutine continue executing a bit earlier than we would have liked. Eventually the GC will attempt the real wakeup of the goroutine, leading recursively to any of the cases in this list. * The goroutine cannot be sleeping in bgsweep, because the background sweepers never use select. * The goroutine might be sleeping in netpollblock. If it wakes up, it will crash with 'fatal error: netpollblock: corrupted state'. * The goroutine might be sleeping in main as another thread crashes. If it wakes up, it will exit(0) instead of letting the other thread crash with a non-zero exit status. * The goroutine cannot be sleeping in forcegchelper, because forcegchelper never uses select. * The goroutine might be sleeping in an empty select - select {}. If it wakes up, it will return to the next line in the program! * The goroutine might be sleeping in a non-empty select (again). In this case, it will wake up spuriously, with gp.param == nil (no reason for wakeup), but that was fortuitously overloaded for handling wakeup due to a closing channel and the way it is handled is to rerun the select, which (accidentally) handles the spurious wakeup correctly: if cas == nil { // This can happen if we were woken up by a close(). // TODO: figure that out explicitly so we don't need this loop. goto loop } Before looping, it will dequeue all the sudogs on all the channels involved, so that no other goroutine will attempt to wake it. Since the goroutine was blocked in select before, being blocked in select again when the spurious wakeup arrives may be quite likely. In this case, the spurious wakeup does no harm (but the stack was still scribbled on). * The goroutine might be sleeping in semacquire (mutex slow path). If it wakes up, that is taken as a signal to try for the semaphore again, not a signal that the semaphore is now held, but the next iteration around the loop will queue the sudog a second time, causing a cycle in the wakeup list for the given address. If that sudog is the only one in the list, when it is eventually dequeued, it will (due to the precise way the code is written) leave the sudog on the queue inactive with the sudog broken. But the sudog will also be in the free list, and that will eventually cause confusion. * The goroutine might be sleeping in notifyListWait, for sync.Cond. If it wakes up, (*Cond).Wait returns. The docs say "Unlike in other systems, Wait cannot return unless awoken by Broadcast or Signal," so the spurious wakeup is incorrect behavior, but most callers do not depend on that fact. Eventually the condition will happen, attempting the real wakeup of the goroutine and leading recursively to any of the cases in this list. * The goroutine might be sleeping in timeSleep aka time.Sleep. If it wakes up, it will continue running, leaving a timer ticking. When that time bomb goes off, it will try to ready the goroutine again, leading to any one of the cases in this list. * The goroutine cannot be sleeping in timerproc, because timerproc never uses select. * The goroutine might be sleeping in ReadTrace. If it wakes up, it will print 'runtime: spurious wakeup of trace reader' and return nil. All future calls to ReadTrace will print 'runtime: ReadTrace called from multiple goroutines simultaneously'. Eventually, when trace data is available, a true wakeup will be attempted, leading to any one of the cases in this list. None of these fatal errors appear in any of the trybot or dashboard logs. The 'bad g->status in ready' that happens if the goroutine is running (the most likely scenario anyway) has happened once on the dashboard and eight times in trybot logs. Of the eight, five were atomicstatus=8 during net/http tests, so almost certainly this bug. The other three were atomicstatus=2, all near code in select, but in a draft CL by Dmitry that was rewriting select and may or may not have had its own bugs. This bug has existed since Go 1.4. Until then the select code was implemented in C, 'done uint32' was a C stack variable 'uint32 done', and C stacks never moved. I believe it has become more common recently because of Brad's work to run more and more tests in net/http in parallel, which lengthens race windows. The fix is to run step 6 on the system stack, avoiding possibility of stack growth. Fixes #17007 and possibly other mysterious failures. Change-Id: I9d6575a51ac96ae9d67ec24da670426a4a45a317 Reviewed-on: https://go-review.googlesource.com/34835 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-on: https://go-review.googlesource.com/35637 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* [release-branch.go1.7] cmd/compile: rewrite literal.method to ensure full ↵David Chase2017-01-252-0/+42
| | | | | | | | | | | | | | | | | | | | initialization CALLPART of STRUCTLIT did not check for incomplete initialization of struct; modify PTRLIT treatment to force zeroing. Test for structlit, believe this might have also failed for arraylit. Fixes #18410. Change-Id: I511abf8ef850e300996d40568944665714efe1fc Reviewed-on: https://go-review.googlesource.com/34622 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-on: https://go-review.googlesource.com/35636 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] time: update test for tzdata-2016gAlberto Donizetti2017-01-251-2/+5
| | | | | | | | | | | Backport of the fix to #17276 for Go 1.7. Change-Id: Ifc1a8e2a81d4e543dbef04566985618884a8c0e0 Reviewed-on: https://go-review.googlesource.com/35635 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
* [release-branch.go1.7] runtime: improve diagnostics for "scan missed a g"Austin Clements2017-01-251-8/+14
| | | | | | | | | | | | | | | | | | | Updates #18700 (backport) Currently there are no diagnostics for mark root check during marking. Fix this by printing out the same diagnostics we print during mark termination. Also, drop the allglock before throwing. Holding that across a throw causes a self-deadlock with tracebackothers. For #16083. Change-Id: Ib605f3ae0c17e70704b31d8378274cfaa2307dc2 Reviewed-on: https://go-review.googlesource.com/35677 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] doc: remove Reddit as an official space where Code of ↵Brad Fitzpatrick2016-12-121-1/+0
| | | | | | | | | | | | Conduct applies Fixes #18289 Change-Id: I047e98cc36b861ef15292170aeaff8bc29243cab Reviewed-on: https://go-review.googlesource.com/34281 Reviewed-by: Russ Cox <rsc@golang.org> (cherry picked from commit 265e547658ac6e91df308326041ea462593053fc) Reviewed-on: https://go-review.googlesource.com/34282
* [release-branch.go1.7] go1.7.4go1.7.4Chris Broadfoot2016-12-011-1/+1
| | | | | | | | Change-Id: I76d2c823eb98c16bb923caad2d0b0e0809a5ee37 Reviewed-on: https://go-review.googlesource.com/33798 Run-TryBot: Chris Broadfoot <cbro@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* [release-branch.go1.7] doc: document go1.7.4 and go1.6.4Chris Broadfoot2016-12-011-0/+13
| | | | | | | | | Change-Id: I0728afe6a1d1e0aee4701e51a5548fa9fd637b66 Reviewed-on: https://go-review.googlesource.com/33795 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/33796 Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] crypto/x509: read Darwin trust settings for root CAsQuentin Smith2016-12-014-11/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Darwin separately stores bits indicating whether a root certificate should be trusted; this changes Go to read and use those when initializing SystemCertPool. Unfortunately, the trust API is very slow. To avoid a delay of up to 0.5s in initializing the system cert pool, we assume that the trust settings found in kSecTrustSettingsDomainSystem will always indicate trust. (That is, all root certs Apple distributes are trusted.) This is not guaranteed by the API but is true in practice. In the non-cgo codepath, we do not have that benefit, so we must check the trust status of every certificate. This causes about 0.5s of delay in initializing the SystemCertPool. On OS X 10.11 and older, the "security" command requires a certificate to be provided in a file and not on stdin, so the non-cgo codepath creates temporary files for each certificate, further slowing initialization. Updates #18141. Change-Id: If681c514047afe5e1a68de6c9d40ceabbce54755 Reviewed-on: https://go-review.googlesource.com/33721 Run-TryBot: Quentin Smith <quentin@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-on: https://go-review.googlesource.com/33727
* [release-branch.go1.7] net/http: multipart ReadForm close file after copyMichael Fraenkel2016-12-011-1/+3
| | | | | | | | | | | | | | | | | Always close the file regardless of whether the copy succeeds or fails. Pass along the close error if the copy succeeds Updates #16296 Fixes #17965 Change-Id: Ib394655b91d25750f029f17b3846d985f673fb50 Reviewed-on: https://go-review.googlesource.com/30410 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/33639 Reviewed-by: Chris Broadfoot <cbro@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
* [release-branch.go1.7] doc: reference go1.4-bootstrap-20161024.tar.gzBrad Fitzpatrick2016-11-081-14/+27
| | | | | | | | | Updates #16352 Change-Id: I214c87579ef21ced8d0ba94aa170dd7780afec4b Reviewed-on: https://go-review.googlesource.com/32312 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/32914
* [release-branch.go1.7] doc/devel/release.html: document go1.6.3 doesn't ↵Shenghou Ma2016-11-081-1/+1
| | | | | | | | | | | | | actually support macOS Sierra Updates #17824. Change-Id: I73cf89c21b418158c7014c3271cd1103a17a5c86 Reviewed-on: https://go-review.googlesource.com/32882 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/32885 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
* [release-branch.go1.7] doc: remove mention of Go 1.6.3 working on SierraBrad Fitzpatrick2016-10-281-2/+1
| | | | | | | | | | | | We thought it would at the time, but then Beta 4 changed the ABI again, so it wasn't true in practice. Fixes #17643 Change-Id: I36b747bd69a56adc7291fa30d6bffdf67ab8741b Reviewed-on: https://go-review.googlesource.com/32238 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-on: https://go-review.googlesource.com/32270
* [release-branch.go1.7] go1.7.3go1.7.3Chris Broadfoot2016-10-191-1/+1
| | | | | | | | Change-Id: I906070c84c0f40c4dd8af8b5894895127834ee00 Reviewed-on: https://go-review.googlesource.com/31438 Run-TryBot: Chris Broadfoot <cbro@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] doc: document go1.7.3 and add note to go1.7.2 that it ↵Chris Broadfoot2016-10-191-3/+9
| | | | | | | | | should not be used Change-Id: I3dd1513e927733ce5c63928da772cb81760ba869 Reviewed-on: https://go-review.googlesource.com/31442 Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] net/http: update bundled http2Chris Broadfoot2016-10-191-23/+10
| | | | | | | | | | | | | | | | | Updates bundled http2 for x/net/http2 git rev d4c55e66 for: [release-branch.go1.7] http2: never Read from Request.Body in Transport to determine ContentLength https://golang.org/cl/31361 Updates #17480 Updates #17071 Change-Id: I2231adaed3cb5b368927a9654dcf7e69a8b664b6 Reviewed-on: https://go-review.googlesource.com/31432 Run-TryBot: Chris Broadfoot <cbro@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] net/http: update test to check Content-Length 0 Body ↵Brad Fitzpatrick2016-10-181-1/+1
| | | | | | | | | | | | | | | | | | | more reliably The way to send an explicitly-zero Content-Length is to set a nil Body. Fix this test to do that, rather than relying on type sniffing. Updates #17480 Updates #17071 Change-Id: I6a38e20f17013c88ec4ea69d73c507e4ed886947 Reviewed-on: https://go-review.googlesource.com/31434 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org> Reviewed-on: https://go-review.googlesource.com/31437 Run-TryBot: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] go1.7.2go1.7.2Chris Broadfoot2016-10-171-1/+1
| | | | | | | | Change-Id: I546e8b1aa4facdbf13bb80d386bf4839a3aff9d1 Reviewed-on: https://go-review.googlesource.com/31314 Run-TryBot: Chris Broadfoot <cbro@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] doc: document go1.7.2Chris Broadfoot2016-10-172-2/+10
| | | | | | | | Change-Id: I34b3650ee9512879ff7528336813a7850c46ea90 Reviewed-on: https://go-review.googlesource.com/31311 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/31313 Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] crypto/{aes,cipher}: fix panic in CBC on s390x when ↵Michael Munday2016-10-172-1/+57
| | | | | | | | | | | | | | | | | | src length is 0 Adds a test to check that block cipher modes accept a zero-length input. Fixes #17435. Change-Id: Ie093c4cdff756b5c2dcb79342e167b3de5622389 Reviewed-on: https://go-review.googlesource.com/31070 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/31291 Reviewed-by: Michael Munday <munday@ca.ibm.com> Run-TryBot: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] cmd/compile: escape analysis needs to run "flood" to ↵David Chase2016-10-172-0/+68
| | | | | | | | | | | | | | | | | | | | | fixed point In some cases the members of the root set from which flood runs themselves escape, without their referents being also tagged as escaping. Fix this by reflooding from those roots whose escape increases, and also enhance the "leak" test to include reachability from a heap-escaped root. Fixes #17318. Change-Id: Ied1e75cee17ede8ca72a8b9302ce8201641ec593 Reviewed-on: https://go-review.googlesource.com/30693 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-on: https://go-review.googlesource.com/31290 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: David Chase <drchase@google.com>
* [release-branch.go1.7] runtime: sleep on CLOCK_MONOTONIC in futexsleep1 on ↵Mike Appleby2016-10-177-11/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | freebsd In FreeBSD 10.0, the _umtx_op syscall was changed to allow sleeping on any supported clock, but the default clock was switched from a monotonic clock to CLOCK_REALTIME. Prior to 10.0, the __umtx_op_wait* functions ignored the fourth argument to _umtx_op (uaddr1), expected the fifth argument (uaddr2) to be a struct timespec pointer, and used a monotonic clock (nanouptime(9)) for timeout calculations. Since 10.0, if callers want a clock other than CLOCK_REALTIME, they must call _umtx_op with uaddr1 set to a value greater than sizeof(struct timespec), and with uaddr2 as pointer to a struct _umtx_time, rather than a timespec. Callers can set the _clockid field of the struct _umtx_time to request the clock they want. The relevant FreeBSD commit: https://svnweb.freebsd.org/base?view=revision&revision=232144 Fixes #17168 Change-Id: I3dd7b32b683622b8d7b4a6a8f9eb56401bed6bdf Reviewed-on: https://go-review.googlesource.com/30154 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/31269
* [release-branch.go1.7] crypto/tls: fix deadlock when racing to complete ↵Adam Langley2016-10-172-15/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | handshake. After renegotiation support was added (af125a5193c) it's possible for a Write to block on a Read when racing to complete the handshake: 1. The Write determines that a handshake is needed and tries to take the neccesary locks in the correct order. 2. The Read also determines that a handshake is needed and wins the race to take the locks. 3. The Read goroutine completes the handshake and wins a race to unlock and relock c.in, which it'll hold when waiting for more network data. If the application-level protocol requires the Write to complete before data can be read then the system as a whole will deadlock. Unfortunately it doesn't appear possible to reverse the locking order of c.in and handshakeMutex because we might read a renegotiation request at any point and need to be able to do a handshake without unlocking. So this change adds a sync.Cond that indicates that a goroutine has committed to doing a handshake. Other interested goroutines can wait on that Cond when needed. The test for this isn't great. I was able to reproduce the deadlock with it only when building with -race. (Because -race happened to alter the timing just enough.) Fixes #17101. Change-Id: I4e8757f7b82a84e46c9963a977d089f0fb675495 Reviewed-on: https://go-review.googlesource.com/29164 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/31268
* [release-branch.go1.7] runtime: fix SIGILL in checkvectorfacility on s390xMichael Munday2016-10-171-0/+1
| | | | | | | | | | | | | | | STFLE does not necessarily write to all the double-words that are requested. It is therefore necessary to clear the target memory before calling STFLE in order to ensure that the facility list does not contain false positives. Fixes #17032. Change-Id: I7bec9ade7103e747b72f08562fe57e6f091bd89f Reviewed-on: https://go-review.googlesource.com/28850 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/31267 Reviewed-by: Michael Munday <munday@ca.ibm.com>
* [release-branch.go1.7] net/http: update bundled http2Brad Fitzpatrick2016-09-151-4/+4
| | | | | | | | | | | | | | | Updates bundled http2 for x/net/http2 git rev 8d4d01f0 for: [release-branch.go1.7] http2: don't sniff first Request.Body byte in Transport until we have a conn https://golang.org/cl/29074 Fixes #17071 Change-Id: I37fef5c2c0fdf499545f9af08abd5f9edb2da4c0 Reviewed-on: https://go-review.googlesource.com/29111 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] doc: fix typo in the release notesMichal Bohuslávek2016-09-081-1/+1
| | | | | | | | Change-Id: I003795d8dc2176532ee133740bf35e23a3aa3878 Reviewed-on: https://go-review.googlesource.com/28811 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/28774 Reviewed-by: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] go1.7.1go1.7.1Chris Broadfoot2016-09-071-1/+1
| | | | | | Change-Id: Id877244fba01ae84255ad2d1f6334d096d5d6f71 Reviewed-on: https://go-review.googlesource.com/28694 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] doc: document go1.7.1Chris Broadfoot2016-09-072-2/+14
| | | | | | | Change-Id: I6bdbf0cafa0f70bdb7c435e45885f5d8f9e05dad Reviewed-on: https://go-review.googlesource.com/28693 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/28692
* [release-branch.go1.7] runtime: fix check for vacuous page boundary rounding ↵Austin Clements2016-09-071-1/+3
| | | | | | | | | | | | | | | | | | | | | again The previous fix for this, commit 336dad2a, had everything right in the commit message, but reversed the test in the code. Fix the test in the code. This reversal effectively disabled the scavenger on large page systems *except* in the rare cases where this code was originally wrong, which is why it didn't obviously show up in testing. Fixes #16644. Again. :( Change-Id: I27cce4aea13de217197db4b628f17860f27ce83e Reviewed-on: https://go-review.googlesource.com/27402 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/28631 Run-TryBot: Chris Broadfoot <cbro@golang.org>
* [release-branch.go1.7] cmd/compile: compare size in dead store eliminationKeith Randall2016-09-072-9/+41
| | | | | | | | | | | | | | | | | This CL is a manual backpatch of CL 27320 into the 1.7.1 release branch. The manual backpatch is required because OpZero changed from having a size as its AuxInt to having a size+align as its AuxInt (that was to support the ARM SSA backend). Otherwise the CLs should be identical. Please review carefully! Change-Id: I569b759c06d1971c9c62dc5dd589abc7ef7c844a Reviewed-on: https://go-review.googlesource.com/28670 Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
* [release-branch.go1.7] syscall: use MNT_NOWAIT in TestGetfsstatBrad Fitzpatrick2016-09-071-7/+24
| | | | | | | | | | | | | | | | | Fixes test failure when VMWare's shared folder filesystem is present. MNT_NOWAIT is what the mount(8) command does. Fixes #16937 Change-Id: Id436185f544b7069db46c8716d6a0bf580b31da0 Reviewed-on: https://go-review.googlesource.com/28550 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-on: https://go-review.googlesource.com/28650 Run-TryBot: Chris Broadfoot <cbro@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] net/http: fix unwanted HTTP/2 conn Transport crash ↵Brad Fitzpatrick2016-09-072-0/+59
| | | | | | | | | | | | | | | | | | after IdleConnTimeout Go 1.7 crashed after Transport.IdleConnTimeout if an HTTP/2 connection was established but but its caller no longer wanted it. (Assuming the connection cache was enabled, which it is by default) Fixes #16208 Change-Id: I9628757f7669e344f416927c77f00ed3864839e3 Reviewed-on: https://go-review.googlesource.com/27450 Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/28637 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] net/http: make Transport.CancelRequest doc recommend ↵Brad Fitzpatrick2016-09-071-2/+3
| | | | | | | | | | | | | | Request.WithContext The old deprecation docs were referencing another deprecated field. Fixes #16752 Change-Id: I44a690048e00ddc790a80214ecb7f5bb0a5b7b34 Reviewed-on: https://go-review.googlesource.com/27510 Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-on: https://go-review.googlesource.com/28638 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] path/filepath: handle ".." in normalizing a path on ↵Hiroshi Ioka2016-09-074-8/+159
| | | | | | | | | | | | | | | | | | | Windows Current code assumes there are not ".." in the Clean(path). That's not true. Clean doesn't handle leading "..", so we need to stop normalization if we see "..". Fixes #16793 Change-Id: I0a7901bedac17f1210b134d593ebd9f5e8483775 Reviewed-on: https://go-review.googlesource.com/27410 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/28641 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] net: restore per-query timeout logicMatthew Dempsky2016-09-072-21/+92
| | | | | | | | | | | | | | The handling of "options timeout:n" is supposed to be per individual DNS server exchange, not per Lookup call. Fixes #16865. Change-Id: I2304579b9169c1515292f142cb372af9d37ff7c1 Reviewed-on: https://go-review.googlesource.com/28057 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/28640
* [release-branch.go1.7] website: recreate 16px and 32px faviconEgon Elbre2016-09-072-0/+238
| | | | | | | | | | | | | Recreated original favicon with svg. Note, the rasterizations are hand tweaked for crispness and straight export will not give the same results. Fixes #6938 Change-Id: I9bf7b59028711361c29365b145932d90af419b69 Reviewed-on: https://go-review.googlesource.com/26850 Reviewed-by: Chris Broadfoot <cbro@golang.org> Reviewed-on: https://go-review.googlesource.com/28639 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] net: don't avoid resolving .local addressesTom Wilkie2016-09-072-7/+9
| | | | | | | | | | | | | | | | | .local addresses are used by things like Kubernetes and Weave DNS; Go should not avoid resolving them. This is a partial revert of https://golang.org/cl/21328 which was too strict of an interpretation of RFC 6762. Fixes #16739 Change-Id: I349415b4eab5d61240dd18217bd95dc7d2105cd5 Reviewed-on: https://go-review.googlesource.com/27250 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/28632
* [release-branch.go1.7] reflect: clear tflag on new typesDavid Crawshaw2016-09-072-0/+4
| | | | | | | | | | | Fixes #16722 Change-Id: I50a0e69d3e79d13bc1860cd983267c3db087a4b8 Reviewed-on: https://go-review.googlesource.com/27119 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/28630
* [release-branch.go1.7] hash/crc32: fix optimized s390x implementationMichael Munday2016-09-072-27/+15
| | | | | | | | | | | | | | | | | | | The code wasn't checking to see if the data was still >= 64 bytes long after aligning it. Aligning the data is an optimization and we don't actually need to do it. In fact for smaller sizes it slows things down due to the overhead of calling the generic function. Therefore for now I have simply removed the alignment stage. I have also added a check into the assembly to deliberately trigger a segmentation fault if the data is too short. Fixes #16779. Change-Id: Ic01636d775efc5ec97689f050991cee04ce8fe73 Reviewed-on: https://go-review.googlesource.com/27409 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/28635
* [release-branch.go1.7] io: fix infinite loop bug in MultiReaderBrad Fitzpatrick2016-09-072-4/+43
| | | | | | | | | | | | | | | | | | | | | | | | If an io.Reader returned (non-zero, EOF), MultiReader would yield bytes forever. This bug has existed before Go 1 (!!), introduced in the original MultiReader implementation in https://golang.org/cl/1764043 and also survived basically the only update to this code since then (https://golang.org/cl/17873, git rev ccdca832c), which was added in Go 1.7. This just bit me when writing a test for some unrelated code. Fixes #16795 Change-Id: I36e6a701269793935d19a47ac12f67b07179fbff Reviewed-on: https://go-review.googlesource.com/27397 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-on: https://go-review.googlesource.com/28633 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] compress/flate: make huffmanBitWriter errors persistentJoe Tsai2016-09-073-14/+78
| | | | | | | | | | | | | | | | | | | | | | | | | For persistent error handling, the methods of huffmanBitWriter have to be consistent about how they check errors. It must either consistently check error *before* every operation OR immediately *after* every operation. Since most of the current logic uses the previous approach, we apply the same style of error checking to writeBits and all calls to Write such that they only operate if w.err is already nil going into them. The error handling approach is brittle and easily broken by future commits to the code. In the near future, we should switch the logic to use panic at the lowest levels and a recover at the edge of the public API to ensure that errors are always persistent. Fixes #16749 Change-Id: Ie1d83e4ed8842f6911a31e23311cd3cbf38abe8c Reviewed-on: https://go-review.googlesource.com/27200 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/28634 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] net/http: update bundled http2 for Transport double ↵Brad Fitzpatrick2016-09-071-2/+10
| | | | | | | | | | | | | | | | | | | STREAM_ENDED error Updates bundled http2 to x/net/http2 git rev 7394c11 for: http2: fix protocol violation regression when writing certain request bodies https://golang.org/cl/27406 Fixes #16788 Change-Id: I0efcd36e2b4b34a1df79f763d35bf7a3a1858506 Reviewed-on: https://go-review.googlesource.com/27451 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-on: https://go-review.googlesource.com/28636 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
* [release-branch.go1.7] doc/go1.7.html: fix name of tls.Config.NextProtosBrad Fitzpatrick2016-08-171-1/+1
| | | | | | | | | Updates #16737 Change-Id: Ia51fc9b06df43b7c6f7136e90b40362263c20081 Reviewed-on: https://go-review.googlesource.com/27126 Reviewed-by: Chris Broadfoot <cbro@golang.org> Reviewed-on: https://go-review.googlesource.com/27234
* [release-branch.go1.7] doc: add 1.7 to golang.org/projectChris Broadfoot2016-08-161-0/+1
| | | | | | | | Change-Id: Ib17f6643efd49e2bca188c4faa505f79832d18b1 Reviewed-on: https://go-review.googlesource.com/27110 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/27112 Reviewed-by: Chris Broadfoot <cbro@golang.org>
View Lorry Controller Status