- 30 Apr, 2015 19 commits
-
-
Alex A Skinner authored
Per resolv.conf man page, "If this file does not exist, only the name server on the local machine will be queried." This behavior also occurs if file is present but unreadable, or if no nameservers are listed. Fixes #10566 Change-Id: Id5716da0eae534d5ebfafea111bbc657f302e307 Reviewed-on: https://go-review.googlesource.com/9380 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I611f7dec2109dc7e2f090ced0a1dca3d4b577134 Reviewed-on: https://go-review.googlesource.com/9520Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Dave Cheney authored
Fix several warnings generated on the linux-amd64-clang builder and make it clear to clang that -znow is a linker only flag. Tested with env CC=clang-3.5 ./all.bash env CC=gcc-4.8 ./all.bash Change-Id: I5ca7366ba8bf6221a36d25a2157dda4b4f3e16fa Reviewed-on: https://go-review.googlesource.com/9523Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
This extends the cgo changes in http://golang.org/cl/8094 to gccgo. It also adds support for setting runtime_iscgo correctly for gccgo; the gc runtime bases the variable on the runtime/cgo package, but gccgo has no equivalent to that package. The go tool supports -buildmode=c-archive for gccgo by linking all the Go objects together using -r. For convenience this object is then put into an archive file. The go tool now passes -fsplit-stack when building C code for gccgo on 386 and amd64. This is required for using -r and will also cut down on unnecessary stack splits. The go tool no longer applies standard package cgo LDFLAGS when using gccgo. This is mainly to avoid getting confused by the LDFLAGS in the runtime/cgo package that gccgo does not use. Change-Id: I1d0865b2a362818a033ca9e9e901d0ce250784e7 Reviewed-on: https://go-review.googlesource.com/9511Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Didier Spezia authored
The current implementation of the tSpecialTagEnd function is inefficient since it generates plenty of memory allocations and converts the whole buffer to lowercase at each call. If the number of special tags increases linearly with the template size, the complexity becomes quadratic. This CL provides an alternative implementation. While the algorithm is probably still not optimal, it avoids the quadratic behavior and the memory allocations. benchmark old ns/op new ns/op delta BenchmarkTemplateSpecialTags-4 19326431 532190 -97.25% benchmark old allocs new allocs delta BenchmarkTemplateSpecialTags-4 2650 190 -92.83% benchmark old bytes new bytes delta BenchmarkTemplateSpecialTags-4 4106460 46568 -98.87% While we are there, make sure we respect the HTML tokenization algorithm. An end tag needs to be followed by a space, tab, CR, FF, /, or > as described in https://html.spec.whatwg.org/multipage/syntax.html#tokenization Explicitly add this check. Fixes #10605 Change-Id: Ia33ddee164ab608a69ac4183e16ec506bbeaa54c Reviewed-on: https://go-review.googlesource.com/9502Reviewed-by: Rob Pike <r@golang.org>
-
Russ Cox authored
Schedule the work as early as possible, while still respecting the utilization percentage on average. The old code tried never to go above the utilization percentage. The new code is willing to go above the utilization percentage by one time slice (but of course after doing that it must wait until the percentage drops back down to the target before it gets another time slice). The effect is that for concurrent GCs that can run in a small number of time slices, the time during which write barriers are enabled is reduced by one mutator + GC time slice round (possibly 30 ms per GC). This only affects the fractional GC processor (the remainder of GOMAXPROCS/4), so it matters most in GOMAXPROCS=1, a bit in GOMAXPROCS=2, and not at all in GOMAXPROCS=4. GOMAXPROCS=1 name old mean new mean delta BenchmarkBinaryTree17 12.4s × (0.98,1.03) 13.5s × (0.97,1.04) +8.84% (p=0.000) BenchmarkFannkuch11 4.38s × (1.00,1.01) 4.38s × (1.00,1.01) ~ (p=0.343) BenchmarkFmtFprintfEmpty 88.9ns × (0.97,1.10) 90.1ns × (0.93,1.14) ~ (p=0.224) BenchmarkFmtFprintfString 356ns × (0.94,1.05) 321ns × (0.94,1.12) -9.77% (p=0.000) BenchmarkFmtFprintfInt 344ns × (0.98,1.03) 325ns × (0.96,1.03) -5.46% (p=0.000) BenchmarkFmtFprintfIntInt 622ns × (0.97,1.03) 571ns × (0.95,1.05) -8.09% (p=0.000) BenchmarkFmtFprintfPrefixedInt 462ns × (0.96,1.04) 431ns × (0.95,1.05) -6.81% (p=0.000) BenchmarkFmtFprintfFloat 653ns × (0.98,1.03) 621ns × (0.99,1.03) -4.90% (p=0.000) BenchmarkFmtManyArgs 2.32µs × (0.97,1.03) 2.19µs × (0.98,1.02) -5.43% (p=0.000) BenchmarkGobDecode 27.0ms × (0.96,1.04) 20.0ms × (0.97,1.04) -26.06% (p=0.000) BenchmarkGobEncode 26.6ms × (0.99,1.01) 17.8ms × (0.95,1.05) -33.19% (p=0.000) BenchmarkGzip 659ms × (0.98,1.03) 650ms × (0.99,1.01) -1.34% (p=0.000) BenchmarkGunzip 145ms × (0.98,1.04) 143ms × (1.00,1.01) -1.47% (p=0.000) BenchmarkHTTPClientServer 111µs × (0.97,1.04) 110µs × (0.96,1.03) -1.30% (p=0.000) BenchmarkJSONEncode 52.0ms × (0.97,1.03) 40.8ms × (0.97,1.03) -21.47% (p=0.000) BenchmarkJSONDecode 127ms × (0.98,1.04) 120ms × (0.98,1.02) -5.55% (p=0.000) BenchmarkMandelbrot200 6.04ms × (0.99,1.04) 6.02ms × (1.00,1.01) ~ (p=0.176) BenchmarkGoParse 8.62ms × (0.96,1.08) 8.55ms × (0.93,1.09) ~ (p=0.302) BenchmarkRegexpMatchEasy0_32 164ns × (0.98,1.05) 165ns × (0.98,1.07) ~ (p=0.293) BenchmarkRegexpMatchEasy0_1K 546ns × (0.98,1.06) 547ns × (0.97,1.07) ~ (p=0.741) BenchmarkRegexpMatchEasy1_32 142ns × (0.97,1.09) 141ns × (0.97,1.05) ~ (p=0.231) BenchmarkRegexpMatchEasy1_1K 904ns × (0.97,1.07) 900ns × (0.98,1.04) ~ (p=0.294) BenchmarkRegexpMatchMedium_32 256ns × (0.98,1.06) 256ns × (0.97,1.04) ~ (p=0.530) BenchmarkRegexpMatchMedium_1K 74.2µs × (0.98,1.05) 73.8µs × (0.98,1.04) ~ (p=0.334) BenchmarkRegexpMatchHard_32 3.94µs × (0.98,1.07) 3.92µs × (0.98,1.05) ~ (p=0.356) BenchmarkRegexpMatchHard_1K 119µs × (0.98,1.07) 119µs × (0.98,1.06) ~ (p=0.467) BenchmarkRevcomp 978ms × (0.96,1.09) 984ms × (0.95,1.07) ~ (p=0.448) BenchmarkTemplate 151ms × (0.96,1.03) 142ms × (0.95,1.04) -5.55% (p=0.000) BenchmarkTimeParse 628ns × (0.99,1.01) 628ns × (0.99,1.01) ~ (p=0.855) BenchmarkTimeFormat 729ns × (0.98,1.06) 734ns × (0.97,1.05) ~ (p=0.149) GOMAXPROCS=2 name old mean new mean delta BenchmarkBinaryTree17-2 9.80s × (0.97,1.03) 9.85s × (0.99,1.02) ~ (p=0.444) BenchmarkFannkuch11-2 4.35s × (0.99,1.01) 4.40s × (0.98,1.05) ~ (p=0.099) BenchmarkFmtFprintfEmpty-2 86.7ns × (0.97,1.05) 85.9ns × (0.98,1.04) ~ (p=0.409) BenchmarkFmtFprintfString-2 297ns × (0.98,1.01) 297ns × (0.99,1.01) ~ (p=0.743) BenchmarkFmtFprintfInt-2 309ns × (0.98,1.02) 310ns × (0.99,1.01) ~ (p=0.464) BenchmarkFmtFprintfIntInt-2 525ns × (0.97,1.05) 518ns × (0.99,1.01) ~ (p=0.151) BenchmarkFmtFprintfPrefixedInt-2 408ns × (0.98,1.02) 408ns × (0.98,1.03) ~ (p=0.797) BenchmarkFmtFprintfFloat-2 603ns × (0.99,1.01) 604ns × (0.98,1.02) ~ (p=0.588) BenchmarkFmtManyArgs-2 2.07µs × (0.98,1.02) 2.05µs × (0.99,1.01) ~ (p=0.091) BenchmarkGobDecode-2 19.1ms × (0.97,1.01) 19.3ms × (0.97,1.04) ~ (p=0.195) BenchmarkGobEncode-2 16.2ms × (0.97,1.03) 16.4ms × (0.99,1.01) ~ (p=0.069) BenchmarkGzip-2 652ms × (0.99,1.01) 651ms × (0.99,1.01) ~ (p=0.705) BenchmarkGunzip-2 143ms × (1.00,1.01) 143ms × (1.00,1.00) ~ (p=0.665) BenchmarkHTTPClientServer-2 149µs × (0.92,1.11) 149µs × (0.91,1.08) ~ (p=0.862) BenchmarkJSONEncode-2 34.6ms × (0.98,1.02) 37.2ms × (0.99,1.01) +7.56% (p=0.000) BenchmarkJSONDecode-2 117ms × (0.99,1.01) 117ms × (0.99,1.01) ~ (p=0.858) BenchmarkMandelbrot200-2 6.10ms × (0.99,1.03) 6.03ms × (1.00,1.00) ~ (p=0.083) BenchmarkGoParse-2 8.25ms × (0.98,1.01) 8.21ms × (0.99,1.02) ~ (p=0.307) BenchmarkRegexpMatchEasy0_32-2 162ns × (0.99,1.02) 162ns × (0.99,1.01) ~ (p=0.857) BenchmarkRegexpMatchEasy0_1K-2 541ns × (0.99,1.01) 540ns × (1.00,1.00) ~ (p=0.530) BenchmarkRegexpMatchEasy1_32-2 138ns × (1.00,1.00) 141ns × (0.98,1.04) +1.88% (p=0.038) BenchmarkRegexpMatchEasy1_1K-2 887ns × (0.99,1.01) 894ns × (0.99,1.01) ~ (p=0.087) BenchmarkRegexpMatchMedium_32-2 252ns × (0.99,1.01) 252ns × (0.99,1.01) ~ (p=0.954) BenchmarkRegexpMatchMedium_1K-2 73.4µs × (0.99,1.02) 72.8µs × (1.00,1.01) -0.87% (p=0.029) BenchmarkRegexpMatchHard_32-2 3.95µs × (0.97,1.05) 3.87µs × (1.00,1.01) -2.11% (p=0.035) BenchmarkRegexpMatchHard_1K-2 117µs × (0.99,1.01) 117µs × (0.99,1.01) ~ (p=0.669) BenchmarkRevcomp-2 980ms × (0.95,1.03) 993ms × (0.94,1.09) ~ (p=0.527) BenchmarkTemplate-2 136ms × (0.98,1.01) 135ms × (0.99,1.01) ~ (p=0.200) BenchmarkTimeParse-2 630ns × (1.00,1.01) 630ns × (1.00,1.00) ~ (p=0.634) BenchmarkTimeFormat-2 705ns × (0.99,1.01) 710ns × (0.98,1.02) ~ (p=0.174) GOMAXPROCS=4 BenchmarkBinaryTree17-4 9.87s × (0.96,1.04) 9.75s × (0.96,1.03) ~ (p=0.178) BenchmarkFannkuch11-4 4.35s × (1.00,1.01) 4.40s × (0.99,1.04) ~ (p=0.071) BenchmarkFmtFprintfEmpty-4 85.8ns × (0.98,1.06) 85.6ns × (0.98,1.04) ~ (p=0.858) BenchmarkFmtFprintfString-4 306ns × (0.99,1.03) 304ns × (0.97,1.02) ~ (p=0.470) BenchmarkFmtFprintfInt-4 317ns × (0.98,1.01) 315ns × (0.98,1.02) -0.92% (p=0.044) BenchmarkFmtFprintfIntInt-4 527ns × (0.99,1.01) 525ns × (0.98,1.01) ~ (p=0.164) BenchmarkFmtFprintfPrefixedInt-4 421ns × (0.98,1.03) 417ns × (0.99,1.02) ~ (p=0.092) BenchmarkFmtFprintfFloat-4 623ns × (0.98,1.02) 618ns × (0.98,1.03) ~ (p=0.172) BenchmarkFmtManyArgs-4 2.09µs × (0.98,1.02) 2.09µs × (0.98,1.02) ~ (p=0.679) BenchmarkGobDecode-4 18.6ms × (0.99,1.01) 18.6ms × (0.98,1.03) ~ (p=0.595) BenchmarkGobEncode-4 15.0ms × (0.98,1.02) 15.1ms × (0.99,1.01) ~ (p=0.301) BenchmarkGzip-4 659ms × (0.98,1.04) 660ms × (0.97,1.02) ~ (p=0.724) BenchmarkGunzip-4 145ms × (0.98,1.04) 144ms × (0.99,1.04) ~ (p=0.671) BenchmarkHTTPClientServer-4 139µs × (0.97,1.02) 138µs × (0.99,1.02) ~ (p=0.392) BenchmarkJSONEncode-4 35.0ms × (0.99,1.02) 35.1ms × (0.98,1.02) ~ (p=0.777) BenchmarkJSONDecode-4 119ms × (0.98,1.01) 118ms × (0.98,1.02) ~ (p=0.710) BenchmarkMandelbrot200-4 6.02ms × (1.00,1.00) 6.02ms × (1.00,1.00) ~ (p=0.289) BenchmarkGoParse-4 7.96ms × (0.99,1.01) 7.96ms × (0.99,1.01) ~ (p=0.884) BenchmarkRegexpMatchEasy0_32-4 164ns × (0.98,1.04) 166ns × (0.97,1.04) ~ (p=0.221) BenchmarkRegexpMatchEasy0_1K-4 540ns × (0.99,1.01) 552ns × (0.97,1.04) +2.10% (p=0.018) BenchmarkRegexpMatchEasy1_32-4 140ns × (0.99,1.04) 142ns × (0.97,1.04) ~ (p=0.226) BenchmarkRegexpMatchEasy1_1K-4 896ns × (0.99,1.03) 907ns × (0.97,1.04) ~ (p=0.155) BenchmarkRegexpMatchMedium_32-4 255ns × (0.99,1.04) 255ns × (0.98,1.04) ~ (p=0.904) BenchmarkRegexpMatchMedium_1K-4 73.4µs × (0.99,1.04) 73.8µs × (0.98,1.04) ~ (p=0.560) BenchmarkRegexpMatchHard_32-4 3.93µs × (0.98,1.04) 3.95µs × (0.98,1.04) ~ (p=0.571) BenchmarkRegexpMatchHard_1K-4 117µs × (1.00,1.01) 119µs × (0.98,1.04) +1.48% (p=0.048) BenchmarkRevcomp-4 990ms × (0.94,1.08) 989ms × (0.94,1.10) ~ (p=0.957) BenchmarkTemplate-4 137ms × (0.98,1.02) 137ms × (0.99,1.01) ~ (p=0.996) BenchmarkTimeParse-4 629ns × (1.00,1.00) 629ns × (0.99,1.01) ~ (p=0.924) BenchmarkTimeFormat-4 710ns × (0.99,1.01) 716ns × (0.98,1.02) +0.84% (p=0.033) Change-Id: I43a04e0f6ad5e3ba9847dddf12e13222561f9cf4 Reviewed-on: https://go-review.googlesource.com/9543Reviewed-by: Austin Clements <austin@google.com>
-
Josh Bleecher Snyder authored
Change-Id: I187e97592cd0403d84ca25c4acb1a4b25495041b Reviewed-on: https://go-review.googlesource.com/9534Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Austin Clements authored
gcDumpObject is used to print the source and destination objects when checkmark find a missing mark. However, gcDumpObject currently assumes the given pointer will point to a heap object. This is not true of the source object during root marking and may not even be true of the destination object in the limited situations where the heap points back in to the stack. If the pointer isn't a heap object, gcDumpObject will attempt an out-of-bounds access to h_spans. This will cause a panicslice, which will attempt to construct a useful panic message. This will cause a string allocation, which will lead mallocgc to panic because the GC is in mark termination (checkmark only happens during mark termination). Fix this by checking that the pointer points into the heap arena before attempting to use it as an arena pointer. Change-Id: I09da600c380d4773f1f8f38e45b82cb229ea6382 Reviewed-on: https://go-review.googlesource.com/9498Reviewed-by: Rick Hudson <rlh@golang.org>
-
Dmitry Vyukov authored
Change-Id: I1add1b92f5c2688a99133d90bf9789d770fd9f05 Reviewed-on: https://go-review.googlesource.com/9503Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Dmitry Vyukov authored
Change-Id: I05cfacd746e87011de8b659ab3b2fbe23146a7f3 Reviewed-on: https://go-review.googlesource.com/9504Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Dmitry Vyukov authored
Currently the packages have the following index functions: func Index(s, sep []byte) int func IndexAny(s []byte, chars string) int func IndexByte(s []byte, c byte) int func IndexFunc(s []byte, f func(r rune) bool) int func IndexRune(s []byte, r rune) int func LastIndex(s, sep []byte) int func LastIndexAny(s []byte, chars string) int func LastIndexFunc(s []byte, f func(r rune) bool) int Searching for the last occurrence of a byte is quite common for string parsing algorithms (e.g. find the last paren on a line). Also addition of LastIndexByte makes the set more orthogonal. Change-Id: Ida168849acacf8e78dd70c1354bef9eac5effafe Reviewed-on: https://go-review.googlesource.com/9500Reviewed-by: Rob Pike <r@golang.org>
-
Alex Brainman authored
This CL copies golang.org/x/sys/windows/registry into internal/syscall/windows/registry (minus KeyInfo.ModTime to prevent dependency cycles). New registry package is used in mime and time packages instead of calling Windows API directly. Change-Id: I965a5a41d4739b3ba38e539a7b8d96d3223e3d56 Reviewed-on: https://go-review.googlesource.com/9271Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan Ford authored
This change adds Int.ModSqrt to compute modular square-roots via the standard Tonelli-Shanks algorithm, and the Jacobi function that this and many other modular-arithmetic algorithms depend on. This is needed by change 1883 (https://golang.org/cl/1883), to add support for ANSI-standard compressed encoding of elliptic curve points. Change-Id: Icc4805001bba0b3cb7200e0b0a7f87b14a9e9439 Reviewed-on: https://go-review.googlesource.com/1886Reviewed-by: Adam Langley <agl@golang.org>
-
Adam Langley authored
The X.509 parser was allowing trailing data after a number of structures in certificates and public keys. There's no obvious security issue here, esp in certificates which are signed anyway, but this change makes trailing data an error just in case. Fixes #10583 Change-Id: Idc289914899600697fc6d30482227ff4bf479241 Reviewed-on: https://go-review.googlesource.com/9473Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Adam Langley authored
This is the second in a two-part change. See https://golang.org/cl/9415 for details of the overall change. This change updates the supported signature algorithms to include SHA-384 and updates all the testdata/ files accordingly. Even some of the testdata/ files named “TLS1.0” and “TLS1.1” have been updated because they have TLS 1.2 ClientHello's even though the server picks a lower version. Fixes #9757. Change-Id: Ia76de2b548d3b39cd4aa3f71132b0da7c917debd Reviewed-on: https://go-review.googlesource.com/9472Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Adam Langley authored
Prior to TLS 1.2, the handshake had a pleasing property that one could incrementally hash it and, from that, get the needed hashes for both the CertificateVerify and Finished messages. TLS 1.2 introduced negotiation for the signature and hash and it became possible for the handshake hash to be, say, SHA-384, but for the CertificateVerify to sign the handshake with SHA-1. The problem is that one doesn't know in advance which hashes will be needed and thus the handshake needs to be buffered. Go ignored this, always kept a single handshake hash, and any signatures over the handshake had to use that hash. However, there are a set of servers that inspect the client's offered signature hash functions and will abort the handshake if one of the server's certificates is signed with a hash function outside of that set. https://robertsspaceindustries.com/ is an example of such a server. Clearly not a lot of thought happened when that server code was written, but its out there and we have to deal with it. This change decouples the handshake hash from the CertificateVerify hash. This lays the groundwork for advertising support for SHA-384 but doesn't actually make that change in the interests of reviewability. Updating the advertised hash functions will cause changes in many of the testdata/ files and some errors might get lost in the noise. This change only needs to update four testdata/ files: one because a SHA-384-based handshake is now being signed with SHA-256 and the others because the TLS 1.2 CertificateRequest message now includes SHA-1. This change also has the effect of adding support for client-certificates in SSLv3 servers. However, SSLv3 is now disabled by default so this should be moot. It would be possible to avoid much of this change and just support SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces and SKX params (a design mistake in TLS). However, that would leave Go in the odd situation where it advertised support for SHA-384, but would only use the handshake hash when signing client certificates. I fear that'll just cause problems in the future. Much of this code was written by davidben@ for the purposes of testing BoringSSL. Partly addresses #9757 Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485 Reviewed-on: https://go-review.googlesource.com/9415 Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
-
Ian Lance Taylor authored
Change-Id: Ie36fd46ad3c0799200fdf4240483a207335570d8 Reviewed-on: https://go-review.googlesource.com/9531Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Mikio Hara authored
Change-Id: I6cebaf42f2596c7f8fef3a67afb1e5ccb428d09c Reviewed-on: https://go-review.googlesource.com/9521Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
This exercises the linker as well as the compiler. Credit to Matthew Dempsky; see #10418. Change-Id: I793947c0c617a34e23df766bff5238ff3ac3c0af Reviewed-on: https://go-review.googlesource.com/9530Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 29 Apr, 2015 21 commits
-
-
Brad Fitzpatrick authored
Fixes #8840 Change-Id: I194d0248734c15336f91a6bcf57ffcc9c0a3a435 Reviewed-on: https://go-review.googlesource.com/9434Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Michael Hudson-Doyle authored
Just a first basic test, I'll extend this to test more but want to get an opinion on basic approach first. Change-Id: Idab9ebd7d9960b000b81a01a1e53258bf4bce755 Reviewed-on: https://go-review.googlesource.com/9386Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
This change deflakes timeout, deadline tests, especially fixes socket and goroutine leaks. Also adds a few missing tests that use features introduced after go1 release. Change-Id: Ibf73a4859f8d4a0ee494ca2fd180cbce72a7a2c7 Reviewed-on: https://go-review.googlesource.com/9464Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
Reduces allocations in the compiler by ~1.5%. No functional changes. Passes toolstash -cmp. Change-Id: I2416f7fb0aaf9b7d6783c79e840039ad8fa7b5a3 Reviewed-on: https://go-review.googlesource.com/9419Reviewed-by: Russ Cox <rsc@golang.org>
-
Mikio Hara authored
This change merges unicast_posix_test.go and multicast_test.go into listen_test.go before deflaking tests for Listen functions. No code changes. Change-Id: Ic4cd6531b95dfb5b6e6e254241692eca61a71e94 Reviewed-on: https://go-review.googlesource.com/9460Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
This change adds missing CloseRead test and Close tests on Conn, Listener and PacketConn with various networks. Change-Id: Iadf99eaf526a323f853d203edc7c8d0577f67972 Reviewed-on: https://go-review.googlesource.com/9469Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Rob Pike authored
Change-Id: I7b15c027c15eefc2a004eb61491e828a7fbefc54 Reviewed-on: https://go-review.googlesource.com/9513Reviewed-by: Russ Cox <rsc@golang.org>
-
Peter Waldschmidt authored
Fixes an issue where Response.Write writes out a Content-Length: -1 header when the corresponding Request is a POST or PUT and the ContentLength was not previously set. This was encountered when using httputil.DumpResponse to write out the response from a server that responded to a PUT request with no Content-Length header. The dumped output is thus invalid. Change-Id: I52c6ae8ef3443f1f9de92aeee9f9581dabb05991 Reviewed-on: https://go-review.googlesource.com/9496Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Mikio Hara authored
Not only by network, transport-layer intermediaries but by virtualization stuff in a node, it is hard to identify the root cause of weird faults without information of packet flows after disaster happened. This change adds Source field to OpError to be able to represent a 5-tuple of internet transport protocols for helping dealing with complicated systems. Also clarifies the usage of Source and Addr fields. Updates #4856. Change-Id: I96a523fe391ed14406bfb21604c461d4aac2fa19 Reviewed-on: https://go-review.googlesource.com/9231Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I77887d247d3e5d60305fc76f962652268827b955 Reviewed-on: https://go-review.googlesource.com/9516Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I5569dcdefe8adba346810124b16721674956bce6 Reviewed-on: https://go-review.googlesource.com/9515Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
tnt authored
RFC 1035 3.3.14 allows a TXT record to contain one or more <character-string>s. The current implementation returns a "no such host" error if there is more than one <character-string> in the TXT record. Fixes #10482 Change-Id: I0ded258005e6b7ba45f687fecd10afa2b321bb77 Reviewed-on: https://go-review.googlesource.com/8966Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Matthew Dempsky authored
The TestAfterQueueing test is inherently flaky because it relies on independent kernel threads being scheduled within the "delta" duration of each other. Normally, delta is 100ms but during "short" testing, it's reduced to 20ms. On at least OpenBSD, the CPU scheduler operates in 10ms time slices, so high system load (e.g., from running multiple Go unit tests in parallel, as happens during all.bash) can occasionally cause >20ms scheduling delays and result in test flaking. This manifests as issue 9903, which is the currently the most common OpenBSD flake. To mitigate this delay, only reduce the delta duration to 20ms for the first attempt during short testing. If this fails and the test is reattempted, subsequent attempts instead use a full 100ms delta. Fixes #9903. Change-Id: I11bdfa939e5be915f67ffad8a8aef6ed8772159a Reviewed-on: https://go-review.googlesource.com/9510 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
For new compile-only builder. Change-Id: Ic374c582fcada761386fc852fdbdba814b4ac9e2 Reviewed-on: https://go-review.googlesource.com/9438Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Benny Siegert authored
Update #10305 Change-Id: Iea04758bc200038a1c64457a68100dcdd7f75212 Reviewed-on: https://go-review.googlesource.com/9440Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
Sequence of operations: - Go code does a systemstack call - during the systemstack call, receive a signal - signal requests a traceback of all goroutines The orignal G is still marked as _Grunning, so the traceback code refuses to print its stack. Fix by allowing traceback of Gs whose caller is on the same M as G is. G can't be modifying its stack if that is the case. Fixes #10546 Change-Id: I2bcea48c0197fbf78ab6fa080027cd80181083ad Reviewed-on: https://go-review.googlesource.com/9435Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Shenghou Ma authored
The problem is not actually specific to android/arm. Linux/ARM's runtime.clone set the stack pointer to child_stk-4 before calling the fn. And then when fn returns, it tries to write to 4(R13) to provide argument for runtime.exit, which is just beyond the allocated child stack, and thus it will corrupt the heap randomly or trigger segfault if that memory happens to be unmapped. While we're at here, shorten the test polling interval to 0.1s to speed up the test (it was only checking at 1s interval, which means the test takes at least 1s). Fixes #10548. Change-Id: I57cd63232022b113b6cd61e987b0684ebcce930a Reviewed-on: https://go-review.googlesource.com/9457Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Rob Pike authored
Print it out much like godoc so there isn't a single block of text. Print the symbol before its comment and indent the comment so individual symbols separate visually. Buffer the output. Add a -c option to force case-sensitive matching. Allow two arguments, like godoc, to help disambiguate cases where path and symbol may be confused. Improve the documentation printed by go help doc. Change-Id: If687aad04bbacdf7dbe4bf7636de9fe96f756fd0 Reviewed-on: https://go-review.googlesource.com/9471Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
The heap statistics were only written if asked for a profile with debug > 0, but that also prints a stack trace for each profile line, which is comparatively much noisier. The statistics are short enough and separate enough (they only appear at the end) and useful enough that we can print them always. This means that people using -test.memprofile in tests will get a memory profile with statistics included now. Pprof won't care, but if people care to look, the numbers will be there. This avoids the need for hacks like using -memprofilerate=1 to find the number of allocations. Change-Id: I10a4f593403d0315aad11b37c6e554b734caa73f Reviewed-on: https://go-review.googlesource.com/9491Reviewed-by: David Chase <drchase@google.com>
-
David Crawshaw authored
Removes the unused *bufio.Reader from the object controlling the linker's primary output. Change-Id: If91d9f60752f3dc4b280f35d6eb441f3c47574b2 Reviewed-on: https://go-review.googlesource.com/9362Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
This doesn't test much with gccgo, but at least it builds now, and the test does, unsurprisingly, pass. A proper test would require adding assembly files in GCC syntax for all platforms that gccgo supports, which would be infeasible. Also added copyright headers to the asm files. Change-Id: Icea5af29d7d521a0681506ddb617a79705b76d33 Reviewed-on: https://go-review.googlesource.com/9417Reviewed-by: Minux Ma <minux@golang.org>
-