- 03 Aug, 2015 2 commits
-
-
Rob Pike authored
Fixes #11973. Change-Id: Icffa3213246663982b7cc795982e0923e272f405 Reviewed-on: https://go-review.googlesource.com/12919Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Andrew Gerrand authored
Change-Id: I992cb1afeef498353d529238e508fa438d6c069c Reviewed-on: https://go-review.googlesource.com/12912Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
- 02 Aug, 2015 3 commits
-
-
ALTree authored
Fixes #11983 Change-Id: I5ee930314a43356f5be31d758d90d7ddcafc7b37 Reviewed-on: https://go-review.googlesource.com/12908Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Jed Denlea authored
HTTP servers attempt to entirely consume a request body before sending a response. However, when doing so, it previously would ignore any errors encountered. Unfortunately, the errors triggered at this stage are indicative of at least a couple problems: read timeouts and chunked encoding errors. This means properly crafted and/or timed requests could lead to a "smuggled" request. The fix is to inspect the errors created by the response body Reader, and treat anything other than io.EOF or ErrBodyReadAfterClose as fatal to the connection. Fixes #11930 Change-Id: I0bf18006d7d8f6537529823fc450f2e2bdb7c18e Reviewed-on: https://go-review.googlesource.com/12865Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Carl Jackson authored
This makes the receiver name consistent with the rest of the methods on type Server. Change-Id: Ic2a007d3b5eb50bd87030e15405e9856109cf590 Reviewed-on: https://go-review.googlesource.com/13035Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
- 31 Jul, 2015 15 commits
-
-
Robert Griesemer authored
Per suggestions by Peter Olsen (https://github.com/pto). Fixes #11964. Change-Id: Iae261ac14f75abf848f5601f59d7fe6e95b6805a Reviewed-on: https://go-review.googlesource.com/13006Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
The test uses external linking mode, which is probably not available if cgo does not work. Fixes #11969. Change-Id: Id1c2828cd2540391e16b422bf51674ba6ff084b0 Reviewed-on: https://go-review.googlesource.com/13005Reviewed-by: Russ Cox <rsc@golang.org>
-
Dave Cheney authored
Fixes #11919 Issue #11918 suggested that os.File.Chown and os.Lchown were under tested. Change-Id: Ib41f7cb2d2fe0066d2ccb4d1bdabe1795efe80fc Reviewed-on: https://go-review.googlesource.com/12834Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Fixes #11960. Change-Id: I9361a9f17f4eaf8e4f54b4ba380fd50a4b9cf003 Reviewed-on: https://go-review.googlesource.com/13023Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
The percolation of errors upward in the load process could drop errors, meaning that a build tree could, depending on the processing order, import the same directory as both "p/vendor/x" and as "x". That's not supposed to be allowed. But then, worse, the build would generate two jobs for building that directory, which would use the same work space and overwrite each other's files, leading to very strange failures. Two fixes: 1. Fix the propagation of errors upward (prefer errors over success). 2. Check explicitly for duplicated packages before starting a build. New test for #1. Since #2 can't happen, tested #2 by hand after reverting fix for #1. Fixes #11913. Change-Id: I6d2fc65f93b8fb5f3b263ace8d5f68d803a2ae5c Reviewed-on: https://go-review.googlesource.com/13022Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
On most systems, a pointer is the worst case alignment, so adding a pointer field at the end of a struct guarantees there will be no padding added after that field (to satisfy overall struct alignment due to some more-aligned field also present). In the runtime, the map implementation needs a quick way to get to the overflow pointer, which is last in the bucket struct, so it uses size - sizeof(pointer) as the offset. NaCl/amd64p32 is the exception, as always. The worst case alignment is 64 bits but pointers are 32 bits. There's a long history that is not worth going into, but when we moved the overflow pointer to the end of the struct, we didn't get the padding computation right. The compiler computed the regular struct size and then on amd64p32 added another 32-bit field. And the runtime assumed it could step back two 32-bit fields (one 64-bit register size) to get to the overflow pointer. But in fact if the struct needed 64-bit alignment, the computation of the regular struct size would have added a 32-bit pad already, and then the code unconditionally added a second 32-bit pad. This placed the overflow pointer three words from the end, not two. The last two were padding, and since the runtime was consistent about using the second-to-last word as the overflow pointer, no harm done in the sense of overwriting useful memory. But writing the overflow pointer to a non-pointer word of memory means that the GC can't see the overflow blocks, so it will collect them prematurely. Then bad things happen. Correct all this in a few steps: 1. Add an explicit check at the end of the bucket layout in the compiler that the overflow field is last in the struct, never followed by padding. 2. When padding is needed on nacl (not always, just when needed), insert it before the overflow pointer, to preserve the "last in the struct" property. 3. Let the compiler have the final word on the width of the struct, by inserting an explicit padding field instead of overwriting the results of the width computation it does. 4. For the same reason (tell the truth to the compiler), set the type of the overflow field when we're trying to pretend its not a pointer (in this case the runtime maintains a list of the overflow blocks elsewhere). 5. Make the runtime use "last in the struct" as its location algorithm. This fixes TestTraceStress on nacl/amd64p32. The 'bad map state' and 'invalid free list' failures no longer occur. Fixes #11838. Change-Id: If918887f8f252d988db0a35159944d2b36512f92 Reviewed-on: https://go-review.googlesource.com/12971Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Mikio Hara authored
Change-Id: Ic8ff6c28ec899cf5e01553b83110eb6262870995 Reviewed-on: https://go-review.googlesource.com/12918Reviewed-by: Russ Cox <rsc@golang.org>
-
MathiasB authored
Fixes some minor issues regarding quoted-string when parsing the local-part. Those strings should return an error: - quoted-string without any content: `""@test.com` - quoted-string containing tab: "\"\t\"@test.com" Fixes #11293 Change-Id: Ied93eb6831915c9b1f8e727cea14168af21f8d3b Reviewed-on: https://go-review.googlesource.com/12905Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
The code already fixed large non-stack offsets but explicitly excluded stack references. Perhaps you could get away with that before, but current versions of nacl reject such stack references. Rewrite them the same as the others. For #11956 but probably not the last problem. Change-Id: I0db4e3a1ed4f88ccddf0d30228982960091d9fb7 Reviewed-on: https://go-review.googlesource.com/13010Reviewed-by: Dave Cheney <dave@cheney.net>
-
Russ Cox authored
For #11956. Change-Id: Ic9b57cafa197953cc7f435941e44d42b60b3ddf0 Reviewed-on: https://go-review.googlesource.com/13011Reviewed-by: Dave Cheney <dave@cheney.net>
-
Andrew Gerrand authored
Update #11943 Change-Id: I3e6592876bf16d2f9129995b723ecf69c069653d Reviewed-on: https://go-review.googlesource.com/12913Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Dangling pointer error. Unlikely to trigger in practice, but still. Found by running GODEBUG=efence=1 GOGC=1 trace.test. Change-Id: Ice474dedcf62dd33ab77526287a023ba3b166db9 Reviewed-on: https://go-review.googlesource.com/12991Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
Etcd and kubernetes have hit this. See https://bugzilla.redhat.com/show_bug.cgi?id=1248071 Change-Id: I6231013efa0a19ee74f7ebacd1024adb368af83a Reviewed-on: https://go-review.googlesource.com/12951Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
In https://golang.org/cl/12080 we forbade installing cross-compiled binaries into a subdirectory of $GOBIN, in order to fix https://golang.org/issue/9769. However, that fix was too aggressive, in that it also forbade installing into a subdirectory of $GOPATH/bin. This patch permits installing cross-compiled binaries into a subdirectory $GOPATH/bin while continuing to forbid installing into a subdirectory of $GOBIN. Fixes #11778. Change-Id: Ibc9919554e8c275beff54ec8bf919cfaa03b11ba Reviewed-on: https://go-review.googlesource.com/12938 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Rob Pike authored
Fixes #11952. Change-Id: I548f9d75c6223bf79bdf654ef733f1568e3d5804 Reviewed-on: https://go-review.googlesource.com/12990Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 30 Jul, 2015 20 commits
-
-
Robert Griesemer authored
The spec didn't specify several aspects of expression switches: - The switch expression is evaluated exactly once. - Switch expressions evaluating to an untyped value are converted to the respective default type before use. - An (untyped) nil value is not permitted as expression switch value. (We could permit it relatively easily, but gc doesn't, and disallowing it is in symmetry with the rules for var decls without explicit type and untyped initializer expressions.) - The comparison x == t between each case expression x and switch expression value t must be valid. - (Some) duplicate constant case expressions are not permitted. This change also clarifies the following issues: 4524: mult. equal int const switch case values should be illegal -> spec issue fixed 6398: switch w/ no value uses bool rather than untyped bool -> spec issue fixed 11578: allows duplicate switch cases -> go/types bug 11667: int overflow in switch expression -> go/types bug 11668: use of untyped nil in switch -> not a gc bug Fixes #4524. Fixes #6398. Fixes #11668. Change-Id: Iae4ab3e714575a5d11c92c9b8fbf027aa706b370 Reviewed-on: https://go-review.googlesource.com/12711Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Rob Pike authored
Change-Id: If61c2063a8b63f0e3e498a5e86803b5ddba9fa3c Reviewed-on: https://go-review.googlesource.com/12886Reviewed-by: Austin Clements <austin@google.com>
-
Brad Fitzpatrick authored
Change-Id: Ie4431e74f095b85b4b5c07d087c3d29acf46d138 Reviewed-on: https://go-review.googlesource.com/12902Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Fixes #11935 Change-Id: Ife00c246345f7d3f96aa95349a35e76671ca7160 Reviewed-on: https://go-review.googlesource.com/12769Reviewed-by: Dave Cheney <dave@cheney.net> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
This should fix the solaris/amd64 builder. Change-Id: Idd6460cc9e842f7b874c9757379986aa723c974c Reviewed-on: https://go-review.googlesource.com/12922Reviewed-by: Austin Clements <austin@google.com>
-
Dave Cheney authored
Fixes #11918 Replace calls to lchown(2) with fchownat(2) for linux/arm64 as the former is not suppored. This change has also landed on the x/sys repo as CL 12837. Change-Id: I58d4b144e051e36dd650ec9b7f3a02610ea943e5 Reviewed-on: https://go-review.googlesource.com/12833Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net> Run-TryBot: Dave Cheney <dave@cheney.net> Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
This documents the change made in https://golang.org/cl/12864 for https://golang.org/issue/11925. Update #11925. Change-Id: Id09f2a489ea947a725ed12c9cf793e5daef07a06 Reviewed-on: https://go-review.googlesource.com/12866Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
This only triggers on ARMv7+. If there are important SMP ARMv6 machines we can reconsider. Makes TestLFStress tests pass and sync/atomic tests not time out on Apple iPad Mini 3. Fixes #7977. Fixes #10189. Change-Id: Ie424dea3765176a377d39746be9aa8265d11bec4 Reviewed-on: https://go-review.googlesource.com/12950Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Robert Griesemer authored
For #11949. Change-Id: I4329604a24efc7f40cf5bf52fb3c9e30916b3cc2 Reviewed-on: https://go-review.googlesource.com/12931Reviewed-by: Alan Donovan <adonovan@google.com>
-
Russ Cox authored
Fixes #11912. Fixes #11937. This reverts commit 1a99ba55. Change-Id: I32b76053fdabc59f28ca5bedf1b15c0baa8afae1 Reviewed-on: https://go-review.googlesource.com/12893Reviewed-by: Didier Spezia <didier.06@gmail.com> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
Was not allocating space for the frame above sigpanic, nor was it pushing the LR into the right place. Because traceback past sigpanic only needs the LR for faulting leaves, this was not noticed too much. But it did break the sync/atomic nil deref tests. Change-Id: Icba53fffa193423aab744c37f21ee893ce2ee3ac Reviewed-on: https://go-review.googlesource.com/12926Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
David Chase authored
ODOTTYPE should be treated a whole lot like ODOT, but it was missing completely from the switch in escwalk and thus escape status did not propagate to fields. Since interfaces are required to trigger this bug, the test was added to escape_iface.go. Fixes #11931. Change-Id: Id0383981cc4b1a160f6ad447192a112eed084538 Reviewed-on: https://go-review.googlesource.com/12921 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
There is absolutely no information about how this was failing. If we reenable the test then at least we can get a build log from darwin/arm. There are not even freebsd/arm or netbsd/arm builders, so not too worried about those. (That is another problem.) Change-Id: I0e739a4dd2897adbe110aa400d720d8fa02ae65f Reviewed-on: https://go-review.googlesource.com/12920Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Instead of pushing the denominator argument on the stack, the denominator is now passed in m. This fixes a variety of bugs related to trying to take stack traces backwards from the middle of the software div/mod routines. Some of those bugs have been kludged around in the past, but others have not. Instead of trying to patch up after breaking the stack, this CL stops breaking the stack. This is an update of https://golang.org/cl/19810043, which was rolled back in https://golang.org/cl/20350043. The problem in the original CL was that there were divisions at bad times, when m was not available. These were divisions by constant denominators, either in C code or in assembly. The Go compiler knows how to generate division by multiplication for constant denominators, but the C compiler did not. There is no longer any C code, so that's taken care of. There was one problematic DIV in runtime.usleep (assembly) but https://golang.org/cl/12898 took care of that one. So now this approach is safe. Reject DIV/MOD in NOSPLIT functions to keep them from coming back. Fixes #6681. Fixes #6699. Fixes #10486. Change-Id: I09a13c76ad08ba75b3bd5d46a3eb78e66a84ab38 Reviewed-on: https://go-review.googlesource.com/12899Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
In order to fix issue #9401 the compiler was changed to add a padding byte to any non-empty Go struct that ends in a zero-sized field. That causes the Go version of such a C struct to have a different size than the C struct, which can considerable confusion. Change cgo so that it discards any such zero-sized fields, so that the Go and C structs are the same size. This is a change from previous releases, in that it used to be possible to refer to a zero-sized trailing field (by taking its address), and with this change it no longer is. That is unfortunate, but something has to change. It seems better to visibly break programs that do this rather than to silently break programs that rely on the struct sizes being the same. Update #9401. Fixes #11925. Change-Id: I3fba3f02f11265b3c41d68616f79dedb05b81225 Reviewed-on: https://go-review.googlesource.com/12864Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
We want to adjust the DIV calling convention to use m, and usleep can be called without an m, so switch to a multiplication by the reciprocal (and test). Step toward a fix for #6699 and #10486. Change-Id: Iccf76a18432d835e48ec64a2fa34a0e4d6d4b955 Reviewed-on: https://go-review.googlesource.com/12898Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
If a function is large enough to need to flush the constant pool mid-function, the line number assignment code was forcing the line numbers not just for the constant pool but for all the instructions that follow it. This made the line number information completely wrong for all but the beginning of large functions on arm. Same problem in code copied into arm64. This broke runtime/trace's TestTraceSymbolize. Fixes arm build. Change-Id: I84d9fb2c798c4085f69b68dc766ab4800c7a6ca4 Reviewed-on: https://go-review.googlesource.com/12894Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
This allows running a cross-compile like GOOS=darwin GOARCH=arm go build std to check that everything builds. Otherwise there is a redefinition error because both root_nocgo_darwin.go and root_darwin_armx.go supply initSystemRoots. Change-Id: Ic95976b2b698d28c629bfc93d8dac0048b023578 Reviewed-on: https://go-review.googlesource.com/12897Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
The test expects the dial to take 1.0 seconds on Windows and allows it to go to 1.095 seconds. That's far too optimistic. Recent failures are reporting roughly 1.2 seconds. Let it have 1.5. Change-Id: Id69811ccb65bf4b4c159301a2b4767deb6ee8d28 Reviewed-on: https://go-review.googlesource.com/12895Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Andrey Petrov authored
Urge users of math/rand to consider using crypto/rand when doing security-sensitive work. Related to issue #11871. While we haven't reached consensus on how to make the package inherently safer, everyone agrees that the docs for math/rand can be improved. Change-Id: I576a312e51b2a3445691da6b277c7b4717173197 Reviewed-on: https://go-review.googlesource.com/12900Reviewed-by: Rob Pike <r@golang.org>
-