- 04 Aug, 2015 1 commit
-
-
Caleb Spare authored
Change-Id: I4dc75065038a9cfd06f61c0deca1c86c70713d3a Reviewed-on: https://go-review.googlesource.com/13091Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 03 Aug, 2015 7 commits
-
-
Russ Cox authored
This was confusing when I was trying to fix go build -o. Perhaps due to that fix, this can now be simplified from three functions to one. Change-Id: I878a6d243b14132a631e7c62a3bb6d101bc243ea Reviewed-on: https://go-review.googlesource.com/13027Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Quoting the new docs: « If the arguments to build are a list of .go files, build treats them as a list of source files specifying a single package. When compiling a single main package, build writes the resulting executable to an output file named after the first source file ('go build ed.go rx.go' writes 'ed' or 'ed.exe') or the source code directory ('go build unix/sam' writes 'sam' or 'sam.exe'). The '.exe' suffix is added when writing a Windows executable. When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built. The -o flag, only allowed when compiling a single package, forces build to write the resulting executable or object to the named output file, instead of the default behavior described in the last two paragraphs. » There is a change in behavior here, namely that 'go build -o x.a x.go' where x.go is not a command (not package main) did not write any output files (back to at least Go 1.2) but now writes x.a. This seems more reasonable than trying to explain that -o is sometimes silently ignored. Otherwise the behavior is unchanged. The lines being deleted in goFilesPackage look like they are setting up 'go build x.o' to write 'x.a', but they were overridden by the p.target = "" in runBuild. Again back to at least Go 1.2, 'go build x.go' for a non-main package has never produced output. It seems better to keep it that way than to change it, both for historical consistency and for consistency with 'go build strings' and 'go build std'. All of this behavior is now tested. Fixes #10865. Change-Id: Iccdf21f366fbc8b5ae600a1e50dfe7fc3bff8b1c Reviewed-on: https://go-review.googlesource.com/13024Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dave Day <djd@golang.org>
-
Brad Fitzpatrick authored
It was failing with multiple goroutines a few out of every thousand runs (with errRequestCanceled) because it was using the same *http.Request for all 5 RoundTrips, but the RoundTrips' goroutines (notably the readLoop method) were all still running, sharing that same pointer. Because the response has no body (which is what TestZeroLengthPostAndResponse tests), the readLoop was marking the connection as reusable early (before the caller read until the body's EOF), but the Transport code was clearing the Request's cancelation func *AFTER* the caller had already received it from RoundTrip. This let the test continue looping and do the next request with the same pointer, fetch a connection, and then between getConn and roundTrip have an invariant violated: the Request's cancelation func was nil, tripping this check: if !pc.t.replaceReqCanceler(req.Request, pc.cancelRequest) { pc.t.putIdleConn(pc) return nil, errRequestCanceled } The solution is to clear the request cancelation func in the readLoop goroutine in the no-body case before it's returned to the caller. This now passes reliably: $ go test -race -run=TestZeroLengthPostAndResponse -count=3000 I think we've only seen this recently because we now randomize scheduling of goroutines in race mode (https://golang.org/cl/11795). This race has existed for a long time but the window was hard to hit. Change-Id: Idb91c582919f85aef5b9e5ef23706f1ba9126e9a Reviewed-on: https://go-review.googlesource.com/13070 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Introduced in https://go-review.googlesource.com/12865 (git rev c2db5f4c). This fix doesn't add any new lock acquistions: it just moves the existing one taken by the unreadDataSize method and moves it out wider. It became flaky at rev c2db5f4c, but now reliably passes again: $ go test -v -race -run=TestTransportAndServerSharedBodyRace -count=100 net/http Fixes #11985 Change-Id: I6956d62839fd7c37e2f7441b1d425793f4a0db30 Reviewed-on: https://go-review.googlesource.com/12909 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Updates #11990. Change-Id: I6c58923a1b5a3805acfb6e333e3c9e87f4edf4ba Reviewed-on: https://go-review.googlesource.com/13050Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
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 14 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>
-