- 21 Dec, 2016 7 commits
-
-
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>
-
- 19 Dec, 2016 7 commits
-
-
Shenghou Ma authored
Fixes #18041. Change-Id: Iad1439b2dd56b113c8829699eda467d1367b0e15 Reviewed-on: https://go-review.googlesource.com/34610Reviewed-by: Austin Clements <austin@google.com>
-
Austin Clements authored
The runtime no longer hard-codes the offset of reflect.methodValue.stack, so remove these obsolete comments. Also, reflect.methodValue and runtime.reflectMethodValue must also agree with reflect.makeFuncImpl, so update the comments on all three to mention this. This was pointed out by Minux on CL 31138. Change-Id: Ic5ed1beffb65db76aca2977958da35de902e8e58 Reviewed-on: https://go-review.googlesource.com/34590Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
Make sure we generate the right code for zeroing a structure. Check in after Matthew's CL (34564). Update #18370 Change-Id: I987087f979d99227a880b34c44d9d4de6c25ba0c Reviewed-on: https://go-review.googlesource.com/34565Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Keith Randall <khr@golang.org>
-
Alberto Donizetti authored
Fixes #18191 Change-Id: Ic2bac9d2a6f42d14e780c74d9c842ee344ab030a Reviewed-on: https://go-review.googlesource.com/34512Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
golang.org/cl/31572 disabled some write barrier optimizations, but inadvertantly disabled optimizations for some non-pointer composite literal assignments too. Fixes #18370. Change-Id: Ia25019bd3016b6ab58173298c7d16202676bce6b Reviewed-on: https://go-review.googlesource.com/34564 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Mikio Hara authored
Change-Id: Id0044c45c23c12ee0bca362a9cdd25369ed7776c Reviewed-on: https://go-review.googlesource.com/34533 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Hudson-Doyle authored
golang.org/issue/17594 was caused by additab being called more than once for an itab. golang.org/cl/32131 fixed that by making the itabs local symbols, but that in turn causes golang.org/issue/18252 because now there are now multiple itab symbols in a process for a given (type,interface) pair and different code paths can end up referring to different itabs which breaks lots of reflection stuff. So this makes itabs global again and just takes care to only call additab once for each itab. Fixes #18252 Change-Id: I781a193e2f8dd80af145a3a971f6a25537f633ea Reviewed-on: https://go-review.googlesource.com/34173 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
- 16 Dec, 2016 6 commits
-
-
Joe Tsai authored
Use the new "Deprecated:" syntax for all instances of HasPrefix. This is a follow-up to http://golang.org/cl/28413 which only modified path_unix.go. In this CL, we avoid mentioning that strings.HasPrefix should be used since that function is still subtly wrong in security applications. See http://golang.org/cl/5712045 for more information. Fixes #18355 Change-Id: I0d0306152cd0b0ea5110774c2c78117515b9f5cd Reviewed-on: https://go-review.googlesource.com/34554 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
It takes me several minutes every time I want to find where the linker writes out the _func structures. Add some comments to make this easier. Change-Id: Ic75ce2786ca4b25726babe3c4fe9cd30c85c34e2 Reviewed-on: https://go-review.googlesource.com/34390Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Kevin Burke authored
Change-Id: Id10e41fe396156106f63a4b29d673b31bea5358f Reviewed-on: https://go-review.googlesource.com/34551Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Fixes #18181. Change-Id: I5eed99dfb7b013aa4d4e668e95a97f5bb643d307 Reviewed-on: https://go-review.googlesource.com/34531 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
In the sampling tests, let the test pass if we get at least 10 samples. Fixes #18332. Change-Id: I8aad083d1a0ba179ad6663ff43f6b6b3ce1e18cd Reviewed-on: https://go-review.googlesource.com/34507Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
Confirm that a trivial executable can build and execute using -fsanitize=memory. Fixes #18335 (by skipping the tests when they don't work). Change-Id: Icb7a276ba7b57ea3ce31be36f74352cc68dc89d5 Reviewed-on: https://go-review.googlesource.com/34505 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 15 Dec, 2016 6 commits
-
-
Bryan C. Mills authored
This fixes Linux and the *BSD platforms on 386/amd64. A few OS/arch combinations were already saving registers and/or doing something that doesn't clearly resemble the SysV C ABI; those have been left alone. Fixes #18328. Change-Id: I6398f6c71020de108fc8b26ca5946f0ba0258667 Reviewed-on: https://go-review.googlesource.com/34501 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
I haven't been able to reproduce this one, but change a few suspect things in this test. Notably, using the global "Get" function and thus using the DefaultTransport was buggy in a parallel test. Then add some error checks and close a TCP connection. Hopefully the failure wasn't timing-related. Fixes #18036 (I hope) Change-Id: I4904e42e40b26d488cf82111424a1d4d46f42dae Reviewed-on: https://go-review.googlesource.com/34490 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Vladimir Stefanovic authored
Change-Id: I496bceacb6b3f417e36dc725d988b12c59a200d5 Reviewed-on: https://go-review.googlesource.com/34412Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
Change-Id: I0d990d494ee8eebfc804b526f5ced71944572b4d Reviewed-on: https://go-review.googlesource.com/34491 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Chris Broadfoot authored
Change-Id: I3ec00dac5e7d0e6dcafb7d65851bc53e0661c2b6 Reviewed-on: https://go-review.googlesource.com/34500Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Chris Broadfoot authored
Updates bundled x/net/http2 to git rev 1195a05d for: http2: fix incorrect panic https://golang.org/cl/34498 http2: fix race in writePushPromise https://golang.org/cl/34493 http2: speed up TestTransportFlowControl in short mode https://golang.org/cl/33241 http2: don't flush a stream's write queue in sc.resetStream https://golang.org/cl/34238 http2: allow Transport to connect to https://[v6literal]/ without port https://golang.org/cl/34143 http2: log Framer reads and writes when a server test fails https://golang.org/cl/34130 Updates #18326 Updates #18273 Updates #18111 Updates #18248 Updates #18235 Change-Id: I18c7a297fc94d6a843284efcfc43e0fdab9b5f41 Reviewed-on: https://go-review.googlesource.com/34495 Run-TryBot: Chris Broadfoot <cbro@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-