Android on ChromeOS uses a restrictive seccomp filter that blocks
sched_getaffinity, leading this code to index a slice by -errno.
Change-Id: Iec09a4f79dfbc17884e24f39bcfdad305de75b37
Reviewed-on: https://go-review.googlesource.com/34794
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Given
var t struct{ lock sync.Mutex }
var fntab []func(t)
f(a(), b(&t), c(), fntab[0](t))
Before:
function call copies lock value: struct{lock sync.Mutex} contains sync.Mutex
After:
call of fntab[0] copies lock value: struct{lock sync.Mutex} contains sync.Mutex
This will make diagnosis easier when there are multiple function calls per line.
Change-Id: I9881713c5671b847b84a0df0115f57e7cba17d72
Reviewed-on: https://go-review.googlesource.com/34730
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes misc/cgo/testsigfwd, enabled for mips{,le} with the next commit
(https://golang.org/cl/34646).
Change-Id: I2bec894b0492fd4d84dd73a4faa19eafca760107
Reviewed-on: https://go-review.googlesource.com/34645
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Clean up the phrasing a little bit, make the comment fit in 80
characters, and fix the spelling of "guard."
Change-Id: I688a3e760b8d67ea83830635f64dff04dd9a5911
Reviewed-on: https://go-review.googlesource.com/34792
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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/34716
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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/34791
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
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/34723
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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/34720
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#6772.
Lock-in test for invalid range loop: repeated variables in range declaration.
Change-Id: I37dd8b1cd7279abe7810deaf8a5d485c5c3b73ca
Reviewed-on: https://go-review.googlesource.com/34714
Reviewed-by: Keith Randall <khr@golang.org>
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/34712
Reviewed-by: Keith Randall <khr@golang.org>
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/34665
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
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/34641
Reviewed-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>
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>
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/34634
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Xcode 8.0 has been donen't support the iOS 5 anymore
Fixes#18390.
Change-Id: Icc97e09424780c610a8fe173d0cf461d76b06da4
Reviewed-on: https://go-review.googlesource.com/34673
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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/34660
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
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/34633
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Wait longer in case the system is heavily loaded.
Fixes#18324.
Change-Id: If9a6da1cf32d0321302d244ee24fb3f80e54489d
Reviewed-on: https://go-review.googlesource.com/34653
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also tweak one of the comment lines to fit in 80 characters.
Change-Id: I9c6d2028c29318ba9264486590056cb1ffc8219e
Reviewed-on: https://go-review.googlesource.com/34655
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
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 #18359Fixes#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>
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>
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/34590
Reviewed-by: Keith Randall <khr@golang.org>
