- 06 Jan, 2016 16 commits
-
-
Alex Brainman authored
Do not check DaylightName if DynamicDaylightTimeDisabled is false. Fixes #13502 Change-Id: I03e01ec0afdeb0037a5d3ee243674e5a6b559da5 Reviewed-on: https://go-review.googlesource.com/17998Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com> Reviewed-by: Russ Cox <rsc@golang.org>
-
Tamir Duberstein authored
Simply checking the exit code of `git rev-parse --git-dir` should suffice here, but that requires deviating from the infrastructure provided by `run`, so I've left that for a future change. Fixes #11211. Change-Id: I7cbad86a8a06578f52f66f734f5447b597ddc962 Reviewed-on: https://go-review.googlesource.com/18213Reviewed-by: Russ Cox <rsc@golang.org>
-
Matthew Dempsky authored
Fixes #13821. Change-Id: I4a28a92d137edac3061537af25ac9d7aba411a66 Reviewed-on: https://go-review.googlesource.com/18262Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Since Stop was introduced, it would revert to the system default for the signal, rather than to the default Go behavior. Change it to revert to the default Go behavior. Change-Id: I345467ece0e49e31b2806d6fce2f1937b17905a6 Reviewed-on: https://go-review.googlesource.com/18229Reviewed-by: Russ Cox <rsc@golang.org>
-
Andrew Gerrand authored
Mention that: - connection pooling is enabled by default, - the Transport is safe for concurrent use, and - the Client type should be used for high-level stuff. Change-Id: Idfd8cc852e733c44211e77cf0e22720b1fdca39b Reviewed-on: https://go-review.googlesource.com/18273Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #13833 Change-Id: If0bd5f7dcfc39d34680d11eb998050f0900d5a26 Reviewed-on: https://go-review.googlesource.com/18283Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Update net/http's copy of http2 (sync as of x/net git rev 961116aee, aka https://golang.org/cl/18266) Also adds some CONNECT tests for #13717 (mostly a copy of http2's version of test, but in the main repo it also tests that http1 behaves the same) Fixes #13668 Fixes #13717 Change-Id: I7db93fe0b7c42bd17a43ef32953f2d20620dd3ea Reviewed-on: https://go-review.googlesource.com/18269 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Also reference the new Transport.ExpectContinueTimeout after the mention of 100-continue. Fixes #13721 Change-Id: I3445c011ed20f29128092c801c7a4bb4dd2b8351 Reviewed-on: https://go-review.googlesource.com/18281Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Ian Lance Taylor authored
Update #11845. Change-Id: I1c248dc48abc62e51836b9ba50d6deb89706c730 Reviewed-on: https://go-review.googlesource.com/18226Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Avoids an msan error when runtime/cgo is explicitly rebuilt with -fsanitize=memory. Fixes #13815. Change-Id: I70308034011fb308b63585bcd40b0d1e62ec93ef Reviewed-on: https://go-review.googlesource.com/18263Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Thanks to Kevin Kirsche (github kkirsche). Change-Id: Ia0017371f56065a5e88d1ebb800a6489136ee9b1 Reviewed-on: https://go-review.googlesource.com/18280Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Adam Langley authored
SEC-1 says: “The component privateKey is the private key defined to be the octet string of length ⌊log₂(n)/8⌋ (where n is the order of the curve)”. Previously the code for parsing ECC private keys would panic (on non-amd64) when the private was too long. It would also pass a too-short private key to crypto/elliptic, possibly resulting in undesirable behaviour. This change makes the parsing function handle both too much and too little padding because GnuTLS does the former and OpenSSL did the latter until 30cd4ff294252c4b6a4b69cbef6a5b4117705d22. It also causes serialisation to pad private keys correctly. Fixes #13699 Change-Id: If9c2faeaeb45af8a4d7770d784f3d2633e7f8290 Reviewed-on: https://go-review.googlesource.com/18094 Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Kevin Vu authored
Also add relevant test. Fixes #13343. Change-Id: Ib1e65af1d643d501de89adee3618eddbf6c69c9e Reviewed-on: https://go-review.googlesource.com/18159Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tamir Duberstein authored
Change-Id: I45b026f4b4bf23b222a81669280cbe245048022b Reviewed-on: https://go-review.googlesource.com/18212Reviewed-by: Russ Cox <rsc@golang.org>
-
Michael Hudson-Doyle authored
Before golang.org/cl/13921, "go install -buildmode=shared prefix/..." created a file called "libprefix.so", which was obviously a problem when prefix was something like "." or "../". However, now it expands the ... into all the matched packages, joins them with -, which can clearly be a very long name indeed. Because I plan to build shared libraries for Ubuntu by running commands exactly like "go install -buildmode=shared prefix/...", this special cases this to produce the old behaviour (but de-relativises prefix first). Fixes #13714 Change-Id: I4fd8d4934279f9a18cc70a13e4ef3e23f6abcb6e Reviewed-on: https://go-review.googlesource.com/18114Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David Benjamin authored
parseBase128Int compares |shifted| with four, seemingly to ensure the result fits in an int32 on 32-bit platforms where int is 32-bit. However, there is an off-by-one in this logic, so it actually allows five shifts, making the maximum tag number or OID component 2^35-1. Fix this so the maximum is 2^28-1 which should be plenty for OID components and tag numbers while not overflowing on 32-bit platforms. Change-Id: If825b30cc53a0fc08e68ea1a24d265e7eb1a13a4 Reviewed-on: https://go-review.googlesource.com/18225Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
- 05 Jan, 2016 17 commits
-
-
Brad Fitzpatrick authored
These are the easy, automated cases. There were some more where we need to fight Gerrit and the CLA system to extract the appropriate metadata. Updates #12042 Change-Id: Id63ae635ee7efeec4cd372c7d85bb5b1f557951b Reviewed-on: https://go-review.googlesource.com/18264Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Try to reduce feature request bug reports. Change-Id: I713bb715d25d23e084b054aea8e1c3197dde90d4 Reviewed-on: https://go-review.googlesource.com/18222Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
In the beginning, there was no way to cancel an HTTP request. We later added Transport.CancelRequest to cancel an in-flight HTTP request by breaking its underlying TCP connection, but it was hard to use correctly and didn't work in all cases. And its error messages were terrible. Some of those issues were fixed over time, but the most unfixable problem was that it didn't compose well. All RoundTripper implementations had to choose to whether to implement CancelRequest and both decisions had negative consequences. In Go 1.5 we added Request.Cancel, which composed well, worked in all phases, had nice error messages, etc. But we forgot to use it in the implementation of Client.Timeout (a timeout which spans multiple requests and reading request bodies). In Go 1.6 (upcoming), we added HTTP/2 support, but now Client.Timeout didn't work because the http2.Transport didn't have a CancelRequest method. Rather than add a CancelRequest method to http2, officially deprecate it and update the only caller (Client, for Client.Cancel) to use Request.Cancel instead. The http2 Client timeout tests are enabled now. For compatibility, we still use CancelRequest in Client if we don't recognize the RoundTripper type. But documentation has been updated to tell people that CancelRequest is deprecated. Fixes #13540 Change-Id: I15546b90825bb8b54905e17563eca55ea2642075 Reviewed-on: https://go-review.googlesource.com/18260Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Slightly rephrased sentence to emphasize the contents of the Unicode categories w/o repeating the full category name each time. Fixes #13414. Change-Id: Icd32ff1547fa81e866c5937a631c3344bb6087c6 Reviewed-on: https://go-review.googlesource.com/18265Reviewed-by: Rob Pike <r@golang.org>
-
Brad Fitzpatrick authored
In debugging the flaky test in #13825, I discovered that my previous change to tighten and simplify the communication protocol between Transport.roundTrip and persistConn.readLoop in https://golang.org/cl/17890 wasn't complete. This change simplifies it further: the buffered-vs-unbuffered complexity goes away, and we no longer need to re-try channel reads in the select case. It was trying to prioritize channels in the case that two were readable in the select. (it was only failing in the race builder because the race builds randomize select scheduling) The problem was that in the bodyless response case we had to return the idle connection before replying to roundTrip. But putIdleConn previously both added it to the free list (which we wanted), but also closed the connection, which made the caller goroutine (Transport.roundTrip) have two readable cases: pc.closech, and the response. We guarded against similar conditions in the caller's select for two readable channels, but such a fix wasn't possible here, and would be overly complicated. Instead, switch to unbuffered channels. The unbuffered channels were only to prevent goroutine leaks, so address that differently: add a "callerGone" channel closed by the caller on exit, and select on that during any unbuffered sends. As part of the fix, split putIdleConn into two halves: a part that just returns to the freelist, and a part that also closes. Update the four callers to the variants each wanted. Incidentally, the connections were closing on return to the pool due to MaxIdleConnsPerHost (somewhat related: #13801), but this bug could've manifested for plenty of other reasons. Fixes #13825 Change-Id: I6fa7136e2c52909d57a22ea4b74d0155fdf0e6fa Reviewed-on: https://go-review.googlesource.com/18282 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Austin Clements authored
This test triggers a large number of usleep(100)s. linux/arm, openbsd, and solaris have very poor timer resolution on the builders, so usleep(100) actually gives up the whole scheduling quantum. On Linux and OpenBSD (and probably Solaris), profiling signals are only generated when a process completes a whole scheduling quantum, so this test often gets zero profiling signals and fails. Until we figure out what to do about this, skip this test on these platforms. Updates #13405. Change-Id: Ica94e4a8ae7a8df3e5a840504f83ee2ec08727df Reviewed-on: https://go-review.googlesource.com/18252Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Austin Clements <austin@google.com>
-
Ian Lance Taylor authored
Previously, when a program died because of a SIGHUP, SIGINT, or SIGTERM signal it would exit with status 2. This CL fixes the runtime to exit with a status indicating that the program was killed by a signal. Change-Id: Ic2982a2562857edfdccaf68856e0e4df532af136 Reviewed-on: https://go-review.googlesource.com/18156Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Use the current ability to say that we don't do anything with SIGCONT by default, but programs can catch it using signal.Notify if they want. Fixes #8953. Change-Id: I67d40ce36a029cbc58a235cbe957335f4a58e1c5 Reviewed-on: https://go-review.googlesource.com/18185Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Chase authored
Added a format option to inhibit output of .Note field in printing, and enabled that option during export. Added test. Fixes #13777. Change-Id: I739f9785eb040f2fecbeb96d5a9ceb8c1ca0f772 Reviewed-on: https://go-review.googlesource.com/18217Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: David Chase <drchase@google.com>
-
Russ Cox authored
For #10571. Change-Id: I9a42226078b9c52dbe0c65cb101b5f452233e911 Reviewed-on: https://go-review.googlesource.com/18205Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
For #13789. Change-Id: I83973298a35afcf55627f0a72223098306a51f4b Reviewed-on: https://go-review.googlesource.com/18233Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
When 'go tool dist test' stops, it was intended that it first wait for pending background tests, like a failed compilation waits for pending background compiles. But these three lines prevented that. Fix by deleting them. (The actual loop already contains the correct logic to avoid running the others and to wait for what's left.) Change-Id: I4e945495ada903fb0af567910626241bc1c52ba6 Reviewed-on: https://go-review.googlesource.com/18232Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
The CloseNotifier implementation and documentation was substantially changed in https://golang.org/cl/17750 but it was a bit too aggressive. Issue #13666 highlighted that in addition to breaking external projects, even the standard library (httputil.ReverseProxy) didn't obey the new rules about not using CloseNotifier until the Request.Body is fully consumed. So, instead of fixing httputil.ReverseProxy, dial back the rules a bit. It's now okay to call CloseNotify before consuming the request body. The docs now say CloseNotifier may wait to fire before the request body is fully consumed, but doesn't say that the behavior is undefined anymore. Instead, we just wait until the request body is consumed and start watching for EOF from the client then. This CL also adds a test to ReverseProxy (using a POST request) that would've caught this earlier. Fixes #13666 Change-Id: Ib4e8c29c4bfbe7511f591cf9ffcda23a0f0b1269 Reviewed-on: https://go-review.googlesource.com/18144Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
Fixes #13346. Change-Id: Ic903ee90575e8dbe23905d0678d3295745d1d47f Reviewed-on: https://go-review.googlesource.com/18154 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Change-Id: Ia8c1c77590115a5ffda144962436d489ed77a423 Reviewed-on: https://go-review.googlesource.com/18227Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Old behavior: 10 consecutive EPIPE errors on any descriptor cause the program to exit with a SIGPIPE signal. New behavior: an EPIPE error on file descriptors 1 or 2 cause the program to raise a SIGPIPE signal. If os/signal.Notify was not used to catch SIGPIPE signals, this will cause the program to exit with SIGPIPE. An EPIPE error on a file descriptor other than 1 or 2 will simply be returned from Write. Fixes #11845. Update #9896. Change-Id: Ic85d77e386a8bb0255dc4be1e4b3f55875d10f18 Reviewed-on: https://go-review.googlesource.com/18151Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
Fixes #13034. Fixes #13042. Update #9896. Change-Id: I189f381090223dd07086848aac2d69d2c00d80c4 Reviewed-on: https://go-review.googlesource.com/18062Reviewed-by: Russ Cox <rsc@golang.org>
-
- 04 Jan, 2016 7 commits
-
-
Aaron Jacobs authored
Change-Id: I2b61f3b3ecf28d8f6a8dff94d194b6d3d450ea22 Reviewed-on: https://go-review.googlesource.com/17996Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Change-Id: I155633b58e1823344a26c3edf11f5626fae080ee Reviewed-on: https://go-review.googlesource.com/18204Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
For #10571. Change-Id: I4bdad64e2dfd692ef2adccf2e5e82e9b1996a8ea Reviewed-on: https://go-review.googlesource.com/18206Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
-
Russ Cox authored
This CL changes the source file information in the standard library's .a files to say "$GOROOT/src/runtime/chan.go" (with a literal "$GOROOT") instead of spelling out the actual directory. The linker then substitutes the actual $GOROOT (or $GOROOT_FINAL) as appropriate. If people download a binary distribution to an alternate location, following the instructions at https://golang.org/doc/install#install, the code before this CL would end up with source paths pointing to /usr/local/go no matter where the actual sources were. Now the source paths for built binaries will point to the actual sources (hopefully). The source line information in distributed binaries is not affected: those will still say /usr/local/go. But binaries people build themselves (their own programs, not the go distribution programs) will be correct. Fixing this path also fixes the lookup of the runtime-gdb.py file. Fixes #5533. Change-Id: I03729baae3fbd8cd636e016275ee5ad2606e4663 Reviewed-on: https://go-review.googlesource.com/18200 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Didier Spezia authored
Following the parallelization of some tests, a race condition can occur in testcarchive, testshared and testcshared. In some cases, it can result in the go env GOROOT command returning corrupted data, which are then passed to a rm command. Make the shell script more robust by not trusting the result of the go env GOROOT command. It does not really fix the issue, but at least prevent the entire repository to be deleted. Updates #13789 Change-Id: Iaf04a7bd078ed3a82e724e35c4b86e6f756f2a2f Reviewed-on: https://go-review.googlesource.com/18173 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
https://golang.org/cl/18087 added a bunch of t.Parallel calls, which aren't compatible with the afterTest func. But in short mode, afterTest is a no-op. To keep all.bash (short mode) fast, conditionally set t.Parallel when in short mode, but keep it unset for compatibility with afterFunc otherwise. Fixes #13804 Change-Id: Ie841fbc2544e1ffbee43ba1afbe895774e290da0 Reviewed-on: https://go-review.googlesource.com/18143Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Change-Id: I491197e1505d02cd107a8788e5377cf1d0a9828c Reviewed-on: https://go-review.googlesource.com/18157Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-