summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* [dev.garbage] runtime: determine if an object is publicdev.garbageRick Hudson2017-05-253-0/+106
| | | | | | | | | | | | ROC (request oriented collector) needs to determine if an object is visible to other goroutines, i.e. public. In a later CL this will be used by the write barrier and the publishing logic to distinguish between local and public objects and act accordingly. Change-Id: I6a80da9deb21f57e831a2ec04e41477f997a8c33 Reviewed-on: https://go-review.googlesource.com/25056 Reviewed-by: Austin Clements <austin@google.com>
* Merge branch 'master' into dev.garbageAustin Clements2017-01-11292-1409/+5031
|\ | | | | | | Change-Id: I36274cf72b8e1908efc8e375cab7880d7b0b3f43
| * runtime: debug prints for spanBytesAlloc underflowAustin Clements2017-01-101-1/+4
| | | | | | | | | | | | | | | | | | | | Updates #18043. Change-Id: I24e687fdd5521c48b672987f15f0d5de9f308884 Reviewed-on: https://go-review.googlesource.com/34612 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * cmd/compile: insert scheduling checks on loop backedgesDavid Chase2017-01-099-4/+579
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Loop breaking with a counter. Benchmarked (see comments), eyeball checked for sanity on popular loops. This code ought to handle loops in general, and properly inserts phi functions in cases where the earlier version might not have. Includes test, plus modifications to test/run.go to deal with timeout and killing looping test. Tests broken by the addition of extra code (branch frequency and live vars) for added checks turn the check insertion off. If GOEXPERIMENT=preemptibleloops, the compiler inserts reschedule checks on every backedge of every reducible loop. Alternately, specifying GO_GCFLAGS=-d=ssa/insert_resched_checks/on will enable it for a single compilation, but because the core Go libraries contain some loops that may run long, this is less likely to have the desired effect. This is intended as a tool to help in the study and diagnosis of GC and other latency problems, now that goal STW GC latency is on the order of 100 microseconds or less. Updates #17831. Updates #10958. Change-Id: I6206c163a5b0248e3f21eb4fc65f73a179e1f639 Reviewed-on: https://go-review.googlesource.com/33910 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
| * cmd/compile: file line number for //go:xxx directivesRobert Griesemer2017-01-092-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Minimally invasive; fixes a regression from 1.7. Fixes #18459. Change-Id: I93b3b5c05706eaff8ae97a237f770838c1f8778c Reviewed-on: https://go-review.googlesource.com/34721 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * net/http: preserve original HTTP method when possibleJoe Tsai2017-01-092-11/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Go1.7, a 301, 302, or 303 redirect on a HEAD method, would still cause the following redirects to still use a HEAD. In CL/29852 this behavior was changed such that those codes always caused a redirect with the GET method. Fix this such that both GET and HEAD will preserve the method. Fixes #18570 Change-Id: I4bfe69872a30799419e3fad9178f907fe439b449 Reviewed-on: https://go-review.googlesource.com/34981 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * runtime: add table of size classes in a commentAustin Clements2017-01-082-0/+84
| | | | | | | | | | | | | | Change-Id: I52fae67c9aeceaa23e70f2ef0468745b354f8c75 Reviewed-on: https://go-review.googlesource.com/34932 Reviewed-by: Minux Ma <minux@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
| * go/types: fix typogulyasm2017-01-071-1/+1
| | | | | | | | | | | | | | | | Fixes #18562 Change-Id: Ic195a8606f09876e2667e4ef720b84a07d316f4a Reviewed-on: https://go-review.googlesource.com/34939 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * os/user: document the difference between Username and NameKevin Burke2017-01-071-14/+22
| | | | | | | | | | | | | | | | Fixes #18261. Change-Id: I4bd7363aac4e62461f61fd95b3c7a18063412182 Reviewed-on: https://go-review.googlesource.com/34241 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * all: fix misspellingsshawnps2017-01-0717-19/+19
| | | | | | | | | | | | | | | | | | Change-Id: I429637ca91f7db4144f17621de851a548dc1ce76 Reviewed-on: https://go-review.googlesource.com/34923 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * net/http: don't do a background read if we've already done oneIan Lance Taylor2017-01-072-0/+50
| | | | | | | | | | | | | | | | | | | | Fixes #18535 Change-Id: I9e49d33ce357a534529a6b0fcdbc09ff4fa98622 Reviewed-on: https://go-review.googlesource.com/34920 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * cmd/go: add link to env varible guide to set custom GOPATHJaana Burcu Dogan2017-01-072-0/+4
| | | | | | | | | | | | | | | | | | | | | | Also moves the GOPATH env variable guide to golang.org/wiki/SettingGOPATH. Fixes #18294. Change-Id: I88a2ce550df7466f8d2388d86bc8476dcf3c2ad6 Reviewed-on: https://go-review.googlesource.com/34918 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * vendor: update golang.org/x/crypto/chacha20poly1305Mikio Hara2017-01-073-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Updates golang.org/x/crypto/chacha20poly1305 to rev cb497ae for: - chacha20poly1305: fix detection of BMI on amd64 (https://golang.org/cl/34852) - chacha20poly1305: fix typos (https://golang.org/cl/34536) - chacha20poly1305: fix typos (https://golang.org/cl/33855) - chacha20poly1305: fix build constraints (https://golang.org/cl/32391) Change-Id: I3a608b5e21b3a72b5aaa5d0afe6c6cffbb1d6fc1 Reviewed-on: https://go-review.googlesource.com/34871 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * net: disable RFC 6724 Rule 9 for IPv4 addressesMatthew Dempsky2017-01-062-131/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rule 9 arguably doesn't make sense for IPv4 addresses, and so far it has only caused problems (#13283, #18518). Disable it until we hear from users that actually want/need it. Fixes #18518. Change-Id: I7b0dd75d03819cab8e0cd4c29f0c1dc8d2e9c179 Reviewed-on: https://go-review.googlesource.com/34914 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * cmd/compile: rewrite literal.method to ensure full initializationDavid Chase2017-01-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * runtime: fix corruption crash/race between select and stack growthRuss Cox2017-01-061-4/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * runtime: expand HACKING.mdAustin Clements2017-01-061-3/+136
| | | | | | | | | | | | | | | | | | This adds high-level descriptions of the scheduler structures, the user and system stacks, error handling, and synchronization. Change-Id: I1eed97c6dd4a6e3d351279e967b11c6e64898356 Reviewed-on: https://go-review.googlesource.com/34290 Reviewed-by: Rick Hudson <rlh@golang.org>
| * runtime: update big mgc.go commentAustin Clements2017-01-061-63/+66
| | | | | | | | | | | | | | | | | | | | | | The comment describing the overall GC algorithm at the top of mgc.go has gotten woefully out-of-date (and was possibly never correct/complete). Update it to reflect the current workings of the GC and the set of phases that we now divide it into. Change-Id: I02143c0ebefe9d4cd7753349dab8045f0973bf95 Reviewed-on: https://go-review.googlesource.com/34711 Reviewed-by: Rick Hudson <rlh@golang.org>
| * net/http: better failure in TestTransportPersistConnLeakRuss Cox2017-01-061-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If one of the c.Get(ts.URL) results in an error, the child goroutine calls t.Errorf, but the test goroutine gets stuck waiting for <-gotReqCh, so the test hangs and the program is eventually killed (after 10 minutes!). Whatever might have been printed to t.Errorf is never seen. Adjust test so that the test fails cleanly in this case. Still trying to debug why c.Get might fail. It seems to have something to do with occasional connection failures on macOS Sierra. Change-Id: Ia797787bd51ea7cd6deb1192aec89c331c4f2c48 Reviewed-on: https://go-review.googlesource.com/34836 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * runtime: use 4K as the boundary of legal pointersAustin Clements2017-01-063-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the check for legal pointers in stack copying uses _PageSize (8K) as the minimum legal pointer. By default, Linux won't let you map under 64K, but 1) it's less clear what other OSes allow or will allow in the future; 2) while mapping the first page is a terrible idea, mapping anywhere above that is arguably more justifiable; 3) the compiler only assumes the first physical page (4K) is never mapped. Make the runtime consistent with the compiler and more robust by changing the bad pointer check to use 4K as the minimum legal pointer. This came out of discussions on CLs 34663 and 34719. Change-Id: Idf721a788bd9699fb348f47bdd083cf8fa8bd3e5 Reviewed-on: https://go-review.googlesource.com/34890 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
| * net: Fix grammar errorKevin Burke2017-01-061-1/+1
| | | | | | | | | | | | Change-Id: I1c2e17b25ca91be37a18c47e70678c3753070fb8 Reviewed-on: https://go-review.googlesource.com/34827 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
| * net: display the complete BUGS section on every platformMikio Hara2017-01-064-19/+19
| | | | | | | | | | | | | | | | | | | | | | We cannot assume that the platform running documentation service is the target platform. Change-Id: I241ed6f8778169faac9ef49e11dcd40f7422cccc Reviewed-on: https://go-review.googlesource.com/34750 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
| * cmd/compile: avoid n.Right nil dereference on non-existent interface methodsEmmanuel Odeke2017-01-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #18392. Avoid nil dereferencing n.Right when dealing with non-existent self referenced interface methods e.g. type A interface{ Fn(A.Fn) } Instead, infer the symbol name from n.Sym itself. Change-Id: I60d5f8988e7318693e5c8da031285d8d7347b771 Reviewed-on: https://go-review.googlesource.com/34817 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
| * cmd/go: use ProxyFromEnvironment in -insecure mode alsoBrad Fitzpatrick2017-01-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Be consistent on whether the http proxy environment variables are respected regardless of whether -insecure is used. Updates #18519 Change-Id: Ib157eaacfd342dd3bfcd03e64da18c98c609cae3 Reviewed-on: https://go-review.googlesource.com/34818 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * x/crypto/chacha20poly1305: fix detection of BMI on AMD64Lion Yang2017-01-051-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This change uses runtime.support_bmi2 as an additional condition to examine the usability of AVX2 version algorithm, fixes the crash on the platfrom which supports AVX2 but not support BMI2. Fixes #18512 Change-Id: I408c0844ae2eb242dacf70cb9e8cec1b8f3bd941 Reviewed-on: https://go-review.googlesource.com/34851 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * crypto: detect BMI usability on AMD64 for sha1 and sha256Lion Yang2017-01-054-9/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing implementations on AMD64 only detects AVX2 usability, when they also contains BMI (bit-manipulation instructions). These instructions crash the running program as 'unknown instructions' on the architecture, e.g. i3-4000M, which supports AVX2 but not support BMI. This change added the detections for BMI1 and BMI2 to AMD64 runtime with two flags as the result, `support_bmi1` and `support_bmi2`, in runtime/runtime2.go. It also completed the condition to run AVX2 version in packages crypto/sha1 and crypto/sha256. Fixes #18512 Change-Id: I917bf0de365237740999de3e049d2e8f2a4385ad Reviewed-on: https://go-review.googlesource.com/34850 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * cmd/go: retain test binary when go test is run with -mutexprofileKale Blankenship2017-01-052-2/+22
| | | | | | | | | | | | | | | | | | Fixes #18494 Change-Id: I8a190acae6d5f1d20d4e4e4547d84e10e8a7fe68 Reviewed-on: https://go-review.googlesource.com/34793 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
| * net/http/httputil: make DumpRequest and DumpRequestOut recognize http.NoBodyBrad Fitzpatrick2017-01-042-4/+21
| | | | | | | | | | | | | | | | Fixes #18506 Change-Id: I6b0b107296311178938609e878e1ef47a30a463f Reviewed-on: https://go-review.googlesource.com/34814 Reviewed-by: Ian Lance Taylor <iant@golang.org>
| * net/http: make Server cancel its ReadTimeout between requestsBrad Fitzpatrick2017-01-042-0/+38
| | | | | | | | | | | | | | | | | | | | Fixes #18447 Change-Id: I5d60c3632a5ce625d3bac9d85533ce689e301707 Reviewed-on: https://go-review.googlesource.com/34813 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * testing: add missing newlines to error messagesIan Lance Taylor2017-01-041-4/+4
| | | | | | | | | | | | | | | | | | | | No test because in practice these errors never occur. Change-Id: I11c77893ae931fc621c98920cba656790d18ed93 Reviewed-on: https://go-review.googlesource.com/34811 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * cmd/go: add sync/atomic dependency when needed by test coverageRuss Cox2017-01-0414-0/+38
| | | | | | | | | | | | | | | | | | | | Fixes #18486. Change-Id: I359dc4169e04b4123bd41679ea939b06fa754ac2 Reviewed-on: https://go-review.googlesource.com/34830 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * cmd/link: use 64k segment alignment on linux/armRuss Cox2017-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Otherwise 64k pages don't map correctly. Fixes #18408. Change-Id: I85f56682531566d1ff5c655640cd58509514aee8 Reviewed-on: https://go-review.googlesource.com/34629 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
| * runtime: check sched_getaffinity return valueMichael Marineau2017-01-031-0/+3
| | | | | | | | | | | | | | | | | | | | Android on ChromeOS uses a restrictive seccomp filter that blocks sched_getaffinity, leading this code to index a slice by -errno. Change-Id: Iec09a4f79dfbc17884e24f39bcfdad305de75b37 Reviewed-on: https://go-review.googlesource.com/34794 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
| * cmd/vet: include function name or value in copylock messageRob Pike2017-01-033-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given var t struct{ lock sync.Mutex } var fntab []func(t) f(a(), b(&t), c(), fntab[0](t)) Before: function call copies lock value: struct{lock sync.Mutex} contains sync.Mutex After: call of fntab[0] copies lock value: struct{lock sync.Mutex} contains sync.Mutex This will make diagnosis easier when there are multiple function calls per line. Change-Id: I9881713c5671b847b84a0df0115f57e7cba17d72 Reviewed-on: https://go-review.googlesource.com/34730 Reviewed-by: Ian Lance Taylor <iant@golang.org>
| * cmd/dist: enable extLink tests for s390xMichael Munday2017-01-031-1/+1
| | | | | | | | | | | | | | | | Change-Id: Ia97d770cd942a49a34c733643ced7490fc31c736 Reviewed-on: https://go-review.googlesource.com/34795 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
| * cmd/dist: enable extLink tests for mips{,le}Vladimir Stefanovic2017-01-031-1/+1
| | | | | | | | | | | | | | | | Change-Id: I9e37aece5ace374e89bee70962a19f76ae3266bc Reviewed-on: https://go-review.googlesource.com/34646 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * runtime: fix SP alignment in mips{,le} sigfwdVladimir Stefanovic2017-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | Fixes misc/cgo/testsigfwd, enabled for mips{,le} with the next commit (https://golang.org/cl/34646). Change-Id: I2bec894b0492fd4d84dd73a4faa19eafca760107 Reviewed-on: https://go-review.googlesource.com/34645 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * database/sql: fix typo and wordingKevin Burke2017-01-021-6/+6
| | | | | | | | | | | | | | | | | | Clean up the phrasing a little bit, make the comment fit in 80 characters, and fix the spelling of "guard." Change-Id: I688a3e760b8d67ea83830635f64dff04dd9a5911 Reviewed-on: https://go-review.googlesource.com/34792 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * database/sql: prevent Tx.rollback from racing Tx.closeDaniel Theophanes2017-01-022-5/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously Tx.done was being set in close, but in a Tx rollback and Commit are the real closing methods, and Tx.close is just a helper common to both. Prior to this change a multiple rollback statements could be called, one would enter close and begin closing it while the other was still in rollback breaking it. Fix that by setting done in rollback and Commit, not in Tx.close. Fixes #18429 Change-Id: Ie274f60c2aa6a4a5aa38e55109c05ea9d4fe0223 Reviewed-on: https://go-review.googlesource.com/34716 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * cmd/link: don't suggest using nm to find -X nameIan Lance Taylor2017-01-021-2/+0
| | | | | | | | | | | | | | | | | | | | | | It doesn't work if the package name includes a '.' or a non-ASCII character (or '%', '"', or a control character). See #16710 and CL 31970. Update #18246. Change-Id: I1487f462a3dc7b0016fce3aa1ea6239b226e6e39 Reviewed-on: https://go-review.googlesource.com/34791 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * net/http: update bundled http2 for Server WriteTimeout changeBrad Fitzpatrick2016-12-312-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updates http2 to x/net/http2 git rev 8fd7f25 for: http2: clear WriteTimeout in Server https://golang.org/cl/34724 And un-skip the new test. (The new test is a slow test, anyway, so won't affect builders or all.bash, but I verified it now passes.) Updates #18437 Change-Id: Ia91ae702edfd23747a9d6b61da284a5a957bfed3 Reviewed-on: https://go-review.googlesource.com/34729 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Kale B <kale@lemnisys.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * net/http: add test for http2 Server WriteTimeoutKale Blankenship2016-12-301-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Current handling of WriteTimeout for http2 does not extend the timeout on new streams. Disable the WriteTimeout in http2 for 1.8 release. Updates #18437 Change-Id: I20480432ab176f115464434645defb56ebeb6ece Reviewed-on: https://go-review.googlesource.com/34723 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * net/http/httputil: clarify the contract on ReverseProxy's Director.Mike Wiacek2016-12-291-0/+2
| | | | | | | | | | | | | | | | | | | | Avoid potential race conditions by clarifying to implemntors of the ReverseProxy interface, the lifetime of provided http.Request structs. Fixes #18456 Change-Id: I46aa60322226ecc3a0d30fa1ef108e504171957a Reviewed-on: https://go-review.googlesource.com/34720 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
| * cmd/go: fix two formatting issues in documentation of testing flagsDmitri Shuralyov2016-12-282-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove unneeded second colon. Remove unneeded space at the beginning of a line (before a tab). Regenerate alldocs.go with mkalldocs.sh. Updates https://golang.org/cl/28783. Updates https://golang.org/cl/29650. Fixes #18448. Change-Id: I1830136a2b760827d4cec565744807a0fd147584 Reviewed-on: https://go-review.googlesource.com/34718 Reviewed-by: Rob Pike <r@golang.org>
| * cmd/vet: fix copylocks false positive on len(array) and cap(array).Aliaksandr Valialkin2016-12-242-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a follow-up for https://golang.org/cl/24340. Updates #14664. Fixes #18374. Change-Id: I2831556a9014d30ec70d5f91943d18c33db5b390 Reviewed-on: https://go-review.googlesource.com/34630 Reviewed-by: Rob Pike <r@golang.org> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * runtime: document MemStats.BySize fieldsAustin Clements2016-12-231-2/+13
| | | | | | | | | | | | Change-Id: Iae8cdcd84e9b5f5d7c698abc6da3fc2af0ef839a Reviewed-on: https://go-review.googlesource.com/34710 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
| * net: Fix spelling of function name in docKevin Burke2016-12-231-1/+1
| | | | | | | | | | | | Change-Id: I24c6d312f7d0ce52e1958e8031fc8249af0dfca9 Reviewed-on: https://go-review.googlesource.com/34669 Reviewed-by: Minux Ma <minux@golang.org>
| * cmd/pprof: Re-enable weblist and disasmRaul Silvera2016-12-222-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous changes started using the full filename for object files on graph nodes, instead of just the file basename. The basename was still being used when selecting mappings to disassemble for weblist and disasm commands, causing a mismatch. This fixes #18385. It was already fixed on the upstream pprof. Change-Id: I1664503634f2c8cd31743561301631f12c4949c9 Reviewed-on: https://go-review.googlesource.com/34665 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
| * net/http: restore Transport's Request.Body byte sniff in limited casesBrad Fitzpatrick2016-12-223-11/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Go 1.8, we'd removed the Transport's Request.Body one-byte-Read-sniffing to disambiguate between non-nil Request.Body with a ContentLength of 0 or -1. Previously, we tried to see whether a ContentLength of 0 meant actually zero, or just an unset by reading a single byte of the Request.Body and then stitching any read byte back together with the original Request.Body. That historically has caused many problems due to either data races, blocking forever (#17480), or losing bytes (#17071). Thus, we removed it in both HTTP/1 and HTTP/2 in Go 1.8. Unfortunately, during the Go 1.8 beta, we've found that a few people have gotten bitten by the behavior change on requests with methods typically not containing request bodies (e.g. GET, HEAD, DELETE). The most popular example is the aws-go SDK, which always set http.Request.Body to a non-nil value, even on such request methods. That was causing Go 1.8 to send such requests with Transfer-Encoding chunked bodies, with zero bytes, confusing popular servers (including but limited to AWS). This CL partially reverts the no-byte-sniffing behavior and restores it only for GET/HEAD/DELETE/etc requests, and only when there's no Transfer-Encoding set, and the Content-Length is 0 or -1. Updates #18257 (aws-go) bug And also private bug reports about non-AWS issues. Updates #18407 also, but haven't yet audited things enough to declare it fixed. Change-Id: Ie5284d3e067c181839b31faf637eee56e5738a6a Reviewed-on: https://go-review.googlesource.com/34668 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
| * runtime: skip floating point hardware check on AndroidElias Naur2016-12-221-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CL 33652 removed the fake auxv for Android, and replaced it with a /proc/self/auxv fallback. When /proc/self/auxv is unreadable, however, hardware capabilities detection won't work and the runtime will mistakenly think that floating point hardware is unavailable. Fix this by always assuming floating point hardware on Android. Manually tested on a Nexus 5 running Android 6.0.1. I suspect the android/arm builder has a readable /proc/self/auxv and therefore does not trigger the failure mode. Change-Id: I95c3873803f9e17333c6cb8b9ff2016723104085 Reviewed-on: https://go-review.googlesource.com/34641 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Minux Ma <minux@golang.org> Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
View Lorry Controller Status