- 02 Jan, 2017 2 commits
-
-
Daniel Theophanes authored
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/34716Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
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/34791Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 31 Dec, 2016 1 commit
-
-
Brad Fitzpatrick authored
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>
-
- 30 Dec, 2016 1 commit
-
-
Kale Blankenship authored
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/34723Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 29 Dec, 2016 1 commit
-
-
Mike Wiacek authored
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/34720Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 28 Dec, 2016 1 commit
-
-
Dmitri Shuralyov authored
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/34718Reviewed-by: Rob Pike <r@golang.org>
-
- 24 Dec, 2016 2 commits
-
-
Emmanuel Odeke authored
Fixes #6772. Lock-in test for invalid range loop: repeated variables in range declaration. Change-Id: I37dd8b1cd7279abe7810deaf8a5d485c5c3b73ca Reviewed-on: https://go-review.googlesource.com/34714Reviewed-by: Keith Randall <khr@golang.org>
-
Aliaksandr Valialkin authored
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/34630Reviewed-by: Rob Pike <r@golang.org> Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 23 Dec, 2016 3 commits
-
-
Austin Clements authored
Change-Id: Iae8cdcd84e9b5f5d7c698abc6da3fc2af0ef839a Reviewed-on: https://go-review.googlesource.com/34710Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Emmanuel Odeke authored
Fixes #5790. Fixes #18421. * Lock in _ = x1/x2 divide by zero runtime panics since it is actually evaluated and not discarded as in previous versions before Go1.8. * Update a test that was skipping over zerodivide tests that expected runtime panics, enabling us to check for the expected panics. Change-Id: I0af0a6ecc19345fa9763ab2e35b275fb2d9d0194 Reviewed-on: https://go-review.googlesource.com/34712Reviewed-by: Keith Randall <khr@golang.org>
-
Kevin Burke authored
Change-Id: I24c6d312f7d0ce52e1958e8031fc8249af0dfca9 Reviewed-on: https://go-review.googlesource.com/34669Reviewed-by: Minux Ma <minux@golang.org>
-
- 22 Dec, 2016 4 commits
-
-
Raul Silvera authored
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/34665Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
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>
-
Elias Naur authored
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/34641Reviewed-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>
-
Mikio Hara authored
FreeBSD 11 or above uses clang-3.6 or higher by default. Updates #15405. Change-Id: If49ce298130165f9e1525c7fd0fd5aa39099ad53 Reviewed-on: https://go-review.googlesource.com/34675Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 21 Dec, 2016 11 commits
-
-
Ian Lance Taylor authored
Fixes #18381. Change-Id: I0a476cd7f6182c8d4646628477c56c133d5671ee Reviewed-on: https://go-review.googlesource.com/34667 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Fixes #18406 Change-Id: Ifd7342fa8de1d2cac47b9279c1f14ac127ac193c Reviewed-on: https://go-review.googlesource.com/34666Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Austin Clements authored
On Windows, CreateThread occasionally fails with ERROR_ACCESS_DENIED. We're not sure why this is, but the Wine source code suggests that this can happen when there's a concurrent CreateThread and ExitProcess in the same process. Fix this by setting a flag right before calling ExitProcess and halting if CreateThread fails and this flag is set. Updates #18253 (might fix it, but we're not sure this is the issue and can't reproduce it on demand). Change-Id: I1945b989e73a16cf28a35bf2613ffab07577ed4e Reviewed-on: https://go-review.googlesource.com/34616 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Kirill Smelkov authored
Commit 10f75748 (CL 32222) taught AMD64 backend to rewrite series of byte loads or stores with corresponding shifts into a single long or quad load or store + appropriate BSWAP. However it did not added test for stores - only loads were tested. Fix it. NOTE Tests for indexed stores are not added because 10f75748 did not add support for indexed stores - only indexed loads were handled then. Change-Id: I48c867ebe7622ac8e691d43741feed1d40cca0d7 Reviewed-on: https://go-review.googlesource.com/34634Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Kirill Smelkov authored
Since commit cc62bed0 (CL 994043) the pipe deadlock when doing Read+Close or Write+Close on same end was fixed, alas with test for Read+Close case only. Then commit 6d6f3381 (CL 4252057) made a thinko: in the writer path p.werr is checked for != nil and then err is set but there is no break from waiting loop unlike break is there in similar condition for reader. Together with having only Read+Close case tested that made it to leave reintroduced Write+Close deadlock unnoticed. Fix it. Implicitly this also fixes net.Pipe to conform to semantic of net.Conn interface where Close is documented to unblock any blocked Read or Write operations. No test added to net/ since net.Pipe tests are "Assuming that the underlying io.Pipe implementation is solid and we're just testing the net wrapping". The test added in this patch should be enough to cover the breakage. Fixes #18401 Updates #18170 Change-Id: I9e9460b3fd7d220bbe60b726accf86f352aed8d4 Reviewed-on: https://go-review.googlesource.com/34637 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Koichi Shiraishi authored
Xcode 8.0 has been donen't support the iOS 5 anymore Fixes #18390. Change-Id: Icc97e09424780c610a8fe173d0cf461d76b06da4 Reviewed-on: https://go-review.googlesource.com/34673Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Takuya Ueda authored
The ParseExprFrom docs refer to Parse. It meant ParseFile. Fixes #18398 Change-Id: I06fb3b5178c6319e86199823fe4769a8eb9dc49c Reviewed-on: https://go-review.googlesource.com/34671Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
This reverts commit eee727d0 (https://golang.org/cl/29113) The " (.go files ignored due to build tags)" error message is not always accurate. Fixes #18396 Updates #17008 Change-Id: I609653120603a7f6094bc1dc3a83856f4b259241 Reviewed-on: https://go-review.googlesource.com/34662 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Ian Lance Taylor authored
This CL also re-enables the cgo tests that were accidentally disabled in CL 32754. Fixes #18389. Change-Id: I2fdc4fe3ec1f92b7da3db3fa66f4e0f806fc899f Reviewed-on: https://go-review.googlesource.com/34660Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Now with a few more repos included. Add Albert Yu (individual CLA) Add Alessandro Baffa (individual CLA) Add Alexandre Fiori (individual CLA) Add Andrew Austin (individual CLA) Add Andy Finkenstadt (individual CLA) Add Antonio Bibiano (individual CLA) Add Baiju Muthukadan (individual CLA) Add Ben Lubar (individual CLA) Add Euan Kemp (individual CLA) Add Harry Moreno (individual CLA) Add Jason Buberel (corporate CLA for Google Inc.) Add Joop Kiefte (individual CLA) Add Maksym Trykur (individual CLA) Add Mathieu Olivier (individual CLA) Add Nick Leli (individual CLA) Add Nik Nyby (individual CLA) Add Quinn Slack (corporate CLA for Sourcegraph Inc) Add Rafal Jeczalik (individual CLA) Add Raphael Geronimi (individual CLA) Add Ryan Bagwell (individual CLA) Add Steve Francia (corporate CLA for Google Inc.) Add Tristan Colgate (individual CLA) Add Фахриддин Балтаев (individual CLA) Updates #12042 Change-Id: Iab98da8a7a9fd3ee54f716ea358b2d515e1e32c4 Reviewed-on: https://go-review.googlesource.com/34658Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Also retightens test cases for Resolve{TCP,UDP,IP}Addr which are using interface names for specifying IPv6 zone. Updates #14037. Fixes #18362. Change-Id: I7444b6302e2847dfbdab8a0ad5b2e702bed1a3d6 Reviewed-on: https://go-review.googlesource.com/34670 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 20 Dec, 2016 14 commits
-
-
David du Colombier authored
In CL 34650, LookupCNAME was changed so it always returns the canonical DNS host, even when there is no CNAME record. Consequently, TestLookupCNAME was failing on Plan 9, because www.google.com doesn't have a CNAME record. We changed the implementation of lookupCNAME on Plan 9, so it returns the canonical DNS host after a CNAME lookup failure. Fixes #18391. Change-Id: I59f361bfb2c9de3953e998e8ac58c054979210bd Reviewed-on: https://go-review.googlesource.com/34633Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Vladimir Stefanovic authored
Fixes #18105 Change-Id: Id56e8782ff618761ec44b6dc20891c8b48fea8df Reviewed-on: https://go-review.googlesource.com/34632Reviewed-by: Rob Pike <r@golang.org>
-
Brad Fitzpatrick authored
Updates #18347 Updates #9348 Change-Id: I115203b0be3eb2e7e269ff28e2f3c47eeca86038 Reviewed-on: https://go-review.googlesource.com/34657Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Updates #15157 Change-Id: Id280705f4382c3b2323f0eed786a400a184614de Reviewed-on: https://go-review.googlesource.com/34656Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
Fixes #18172. Change-Id: I4a21fb5c0753cced025a03d88a6dd1aa3ee01d05 Reviewed-on: https://go-review.googlesource.com/34650Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com>
-
Austin Clements authored
Stop-the-world and freeze-the-world (used for unhandled panics) are currently not safe to do at the same time. While a regular unhandled panic can't happen concurrently with STW (if the P hasn't been stopped, then the panic blocks the STW), a panic from a _SigThrow signal can happen on an already-stopped P, racing with STW. When this happens, freezetheworld sets sched.stopwait to 0x7fffffff and stopTheWorldWithSema panics because sched.stopwait != 0. Fix this by detecting when freeze-the-world happens before stop-the-world has completely stopped the world and freeze the STW operation rather than panicking. Fixes #17442. Change-Id: I646a7341221dd6d33ea21d818c2f7218e2cb7e20 Reviewed-on: https://go-review.googlesource.com/34611 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Wait longer in case the system is heavily loaded. Fixes #18324. Change-Id: If9a6da1cf32d0321302d244ee24fb3f80e54489d Reviewed-on: https://go-review.googlesource.com/34653Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Shenghou Ma authored
Fixes #18363. Change-Id: Ifc98506d33a6753cd7db8e505cf86d5626fbbad0 Reviewed-on: https://go-review.googlesource.com/34596Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Kevin Burke authored
Also tweak one of the comment lines to fit in 80 characters. Change-Id: I9c6d2028c29318ba9264486590056cb1ffc8219e Reviewed-on: https://go-review.googlesource.com/34655Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Piping into security verify-cert only worked on macOS Sierra, and was flaky for unknown reasons. Users reported that the number of trusted root certs stopped randomly jumping around once they switched to using verify-cert against files on disk instead of /dev/stdin. But even using "security verify-cert" on 150-200 certs took too long. It took 3.5 seconds on my machine. More than 4 goroutines hitting verify-cert didn't help much, and soon started to hurt instead. New strategy, from comments in the code: // 1. Run "security trust-settings-export" and "security // trust-settings-export -d" to discover the set of certs with some // user-tweaked trusy policy. We're too lazy to parse the XML (at // least at this stage of Go 1.8) to understand what the trust // policy actually is. We just learn that there is _some_ policy. // // 2. Run "security find-certificate" to dump the list of system root // CAs in PEM format. // // 3. For each dumped cert, conditionally verify it with "security // verify-cert" if that cert was in the set discovered in Step 1. // Without the Step 1 optimization, running "security verify-cert" // 150-200 times takes 3.5 seconds. With the optimization, the // whole process takes about 180 milliseconds with 1 untrusted root // CA. (Compared to 110ms in the cgo path) Fixes #18203 Change-Id: I4e9c11fa50d0273c615382e0d8f9fd03498d4cb4 Reviewed-on: https://go-review.googlesource.com/34389 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org>
-
Kevin Burke authored
Change-Id: Iac7c4f22dc55c970940af33e0f0470694da5c4a6 Reviewed-on: https://go-review.googlesource.com/34654Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
Change-Id: I5670e9924b21fb2466b2b32aa01a922e9a0a0f8a Reviewed-on: https://go-review.googlesource.com/34652Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
This change reverts the following CLs: CL/18274: handle mtime in NTFS/UNIX/ExtendedTS extra fields CL/30811: only use Extended Timestamp on non-zero MS-DOS timestamps We are reverting support for extended timestamps since the support was not not complete. CL/18274 added full support for reading extended timestamp fields and minimal support for writing them. CL/18274 is incomplete because it made no changes to the FileHeader struct, so timezone information was lost when reading and/or writing. While CL/18274 was a step in the right direction, we should provide full support for high precision timestamps in both the reader and writer. This will probably require that we add a new field of type time.Time. The complete fix is too involved to add in the time remaining for Go 1.8 and will be completed in Go 1.9. Updates #10242 Updates #17403 Updates #18359 Fixes #18378 Change-Id: Icf6d028047f69379f7979a29bfcb319a02f4783e Reviewed-on: https://go-review.googlesource.com/34651 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dhananjay Nakrani authored
Parser doesn't attach some compiler directives to anything in the tree. We have to explicitely retain them in the generated code. This change, makes cover explicitely print out any compiler directive that wasn't handled in the ast.Visitor. Fixes #18285. Change-Id: Ib60f253815e92d7fc85051a7f663a61116e40a91 Reviewed-on: https://go-review.googlesource.com/34563 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-