Change-Id: I4816a788e7b89b76dc70d05f4b176e99684d0680
Reviewed-on: https://go-review.googlesource.com/18830
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

It doesn't work and I don't know why.

Update #14063.

Change-Id: I42735012cf6247eca5336f29fcf713e08c8477f8
Reviewed-on: https://go-review.googlesource.com/18817
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Id82209dc313fa6b54e623eb325412737e7a055fe
Reviewed-on: https://go-review.googlesource.com/18794Reviewed-by: Andrew Gerrand <adg@golang.org>

On NetBSD a signal handler returns to the kernel by calling the
setcontext system call with the context passed to the signal handler.
The implementation of runtime·sigreturn_tramp for amd64, copied from the
NetBSD libc, expects that context address to be in r15.  That works in
the NetBSD libc because r15 is preserved across the call to the signal
handler.  It fails in the Go library because r15 is not preserved.
There are various ways to fix this; this one uses the simple approach,
essentially identical to the one in the NetBSD libc, of preserving r15
across the signal handler proper.

Looking at the code for 386 and arm suggests that they are OK.  However,
I have not actually tested them.

Update #14052.

Change-Id: I2b516b1d05fe5d3b8911e65ca761d621dc37fa1b
Reviewed-on: https://go-review.googlesource.com/18815
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

On NetBSD and DragonFly a newly created thread inherits the signal stack
of the creating thread.  This breaks horribly if both threads get a
signal at the same time.  Fix this by dropping the signal stack in the
newly created thread.  The right signal stack will then get installed
later.

Note that cgo code that calls pthread_create will have the wrong,
duplicated, signal stack in the newly created thread.  I don't see any
way to fix that in Go.  People using cgo to call pthread_create will
have to be aware of the problem.

Fixes #13945.
Fixes #13947.

Change-Id: I0c7bd2cdf9ada575d57182ca5e9523060de34931
Reviewed-on: https://go-review.googlesource.com/18814
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

The TestInterfaceAddrsWithNetsh Windows unit test parses and compares the
output of the "netsh" command against more low level Windows API calls. In
at least two cases, some quirks of netsh cause these comparisons to fail.

One example appears to be wi-fi adapters. After a reboot, before it has
been allowed to connect to a network, netsh for IPv4 will not show an
address, whereas netsh for IPv6 will. If the interface is allowed to
connect, and then disconnected, netsh for IPv4 now shows an address and
the test will pass.

The fix is to not compare netsh output if the interface is down.

A related issue is that the IPv6 version of "netsh" can return an
IPv4-embedded IPv6 address where the IPv4 component of the address
is in decimal form, whilst the test is expecting hexadecimal form.

For example, output might be:

  Address fe80::5efe:192.168.1.7%6 Parameters
    ...

Whilst this is valid notation, the fix is to recognise this format in the
"netsh" output and re-parse the address into the all-hexadecimal
representation that the test is expecting.

Fixes #13981

Change-Id: Ie8366673f4d43d07bad80d6d5d1d6e33f654b6cc
Reviewed-on: https://go-review.googlesource.com/18711Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

LoadX509KeyPair and X509KeyPair don't retain the parsed form of
certificates in their return value because it's generally not needed.
This change makes that clear in the comment.

See https://groups.google.com/d/msg/golang-dev/VResvFj2vF8/Wt6WkVT2AwAJ

Change-Id: Ibb759cd6e84c00f4450a012992088422c0546638
Reviewed-on: https://go-review.googlesource.com/18734Reviewed-by: Russ Cox <rsc@golang.org>

The header was in the wrong place, so the definition of a pipeline
was not in the section labeled "Pipelines".

Fixes #13972

Change-Id: Ibca791a4511ca112047b57091c391f6e959fdd78
Reviewed-on: https://go-review.googlesource.com/18775Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

On HTTP redirect, the HTTP client creates a new request and don't copy
over the Cancel channel. This prevents any redirected request from being
cancelled.

Fixes #14053

Change-Id: I467cdd4aadcae8351b6e9733fc582b7985b8b9d3
Reviewed-on: https://go-review.googlesource.com/18810Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #14007.

Change-Id: I1f73dfccb466d8fd00efbd8c92a31ac538bf5988
Reviewed-on: https://go-review.googlesource.com/18731Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates x/net/http2 to git rev b2ed34f for https://golang.org/cl/18727

Updates #14029 (fixes it enough for Go 1.6)
Fixes #13961

Change-Id: Id301247545507671f4e79df0e7c6ec9c421d5a7c
Reviewed-on: https://go-review.googlesource.com/18728
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

https://golang.org/s/execmodes defines rules for how multiple codes of a go
package work when they end up in the address space of a single process, but
currently the linker blows up in this situation. Fix that by loading all .a
files before any .so files and ignoring duplicate symbols found when loading
shared libraries.

I know this is very very late for 1.6 but at least it should clearly not have
any effect when shared libraries are not in use.

Change-Id: I512ac912937e7502ff58eb5628b658ecce3c38e5
Reviewed-on: https://go-review.googlesource.com/18714Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

so that runtime/race tests are included in the race builder.

Update #14011.

Change-Id: I04ac6e47366fdb1fe84ba89da556c6d38f7d4a47
Reviewed-on: https://go-review.googlesource.com/18686
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #14010.

Change-Id: Idfd4b063eecf453fe00f3e798099023707a65963
Reviewed-on: https://go-review.googlesource.com/18738Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>

I'm not sure what the convert function was intended to be.

Fixes #14011

Change-Id: I29d905bc1827936b9433b20b13b7a0b0ac5f502e
Reviewed-on: https://go-review.googlesource.com/18712Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Ie8cb7c7428ae9026c11643b22f9ecf7977e25f5f
Reviewed-on: https://go-review.googlesource.com/18737Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #14006.

Change-Id: Ia819073677ad6993c02255e23760ee21598427b4
Reviewed-on: https://go-review.googlesource.com/18736
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #13977.

Change-Id: Icf54b4d2d746d30da207d1e17c975d18188b1cf8
Reviewed-on: https://go-review.googlesource.com/18702
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>

The linker already applies the fix for elf32, so this just extends it to elf64.

Inspired by https://github.com/pwaller/goupx

Fixes #13974

Change-Id: I65d92b5be9590657060a0e8e80ff5b86ba40017f
Reviewed-on: https://go-review.googlesource.com/18690Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The timeout means that TestSpecialDomainName will not hang if
the DNS server does not respond to the request.

Fixes #13939

Change-Id: I46e30bbd3c11b6c560656134e704331cf6f8af3f
Reviewed-on: https://go-review.googlesource.com/18661Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates x/net/http2 to git rev 72aa00c6 for https://golang.org/cl/18721
(but actually at https://golang.org/cl/18722 now)

Fixes #14008

Change-Id: If05d5ad51ec0ba5ba7e4fe16605c0a83f0484bc8
Reviewed-on: https://go-review.googlesource.com/18723
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Both mips64 architectures share the same runtime/rt0 file, so
we have to hardcode them in buildall.bash.

Ideally we should have cmd/dist report all supported platforms,
see #12270.

Change-Id: I08ce35cfe0a831af5e1e8255b305efd38386fa52
Reviewed-on: https://go-review.googlesource.com/18687Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I7ccf1b5001d77c4390479f53c0137ab02f98595b
Reviewed-on: https://go-review.googlesource.com/18685
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

No need to say "by default" because there is no alternative and no way
to override. Always HTTP/2.0 is officially spelled HTTP/2 these days.

Fixes #13985 harder

Change-Id: Ib1ec03cec171ca865342b8e7452cd4c707d7b770
Reviewed-on: https://go-review.googlesource.com/18720Reviewed-by: Rob Pike <r@golang.org>

Updates x/net/http2 to git rev 5c0dae8 for https://golang.org/cl/18709

Fixes #14003

Change-Id: I8bc205d6d089107b017e3458bbc7e05f6d0cae60
Reviewed-on: https://go-review.googlesource.com/18730Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #14001

Change-Id: I6f9bc3028345081758d8f537c3aaddb2e254e69e
Reviewed-on: https://go-review.googlesource.com/18708Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #13981.

Change-Id: Id8f3cd56a81a7a993cea5c757e619407da491fed
Reviewed-on: https://go-review.googlesource.com/18710Reviewed-by: Ian Lance Taylor <iant@golang.org>

This is testing code in asm_GOARCH.s, so it's not necessary to run the
test on systems where it doesn't build.

Fixes #13991.

Change-Id: Ia7a2d3a34b32e6987dc67428c1e09e63baf0518a
Reviewed-on: https://go-review.googlesource.com/18707Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Wire up Transport.CloseIdleConnections to http2.Transport.CloseIdleConnections.

Updates x/net/http2 to git rev c92cdcb0 for https://golang.org/cl/18678

Fixes #13975

Change-Id: I1183a31256104ff95ae7621e5788cfeee741b1aa
Reviewed-on: https://go-review.googlesource.com/18679Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

GC assists check gcBlackenEnabled under the assist queue lock to avoid
going to sleep after gcWakeAllAssists has already woken all assists.
However, currently we clear gcBlackenEnabled shortly *after* waking
all assists, which opens a window where this exact race can happen.

Fix this by clearing gcBlackenEnabled before waking blocked assists.
However, it's unlikely this actually matters because the world is
stopped between waking assists and clearing gcBlackenEnabled and there
aren't any obvious allocations during this window, so I don't think an
assist could actually slip in to this race window.

Updates #13645.

Change-Id: I7571f059530481dc781d8fd96a1a40aadebecb0d
Reviewed-on: https://go-review.googlesource.com/18682
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Also adds missing nosplit to unminit.

Fixes #13964.

Change-Id: I07d93a8c872a255a89f91f808b66c889f0a6a69c
Reviewed-on: https://go-review.googlesource.com/18658Reviewed-by: Ian Lance Taylor <iant@golang.org>

If a user starts two HTTP requests when no http2 connection is
available, both end up creating new TCP connections, since the
server's protocol (h1 or h2) isn't yet known. Once it turns out that
the server supports h2, one of the connections is useless. Previously
we kept upgrading both TLS connections to h2 (SETTINGS frame exchange,
etc).  Now the unnecessary connections are closed instead, before the
h2 preface/SETTINGS.

Updates x/net/http2 to git rev a8e212f3d for https://golang.org/cl/18675

This CL contains the tests for https://golang.org/cl/18675

Semi-related change noticed while writing the tests: now that we have
TLSNextProto in Go 1.6, which consults the TLS
ConnectionState.NegotiatedProtocol, we have to gurantee that the TLS
handshake has been done before we look at the ConnectionState. So add
that check after the DialTLS hook. (we never documented that users
have to call Handshake, so do it for them, now that it matters)

Updates #13957

Change-Id: I9a70e9d1282fe937ea654d9b1269c984c4e366c0
Reviewed-on: https://go-review.googlesource.com/18676Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

While the default behavior of eliding runtime frames from tracebacks
usually makes sense, this is not the case when you're trying to test
the runtime itself. Fix this by forcing the traceback level to at
least "system" in the runtime tests.

This will specifically help with debugging issue #13645, which has
proven remarkably resistant to reproduction outside of the build
dashboard itself.

Change-Id: I2a8356ba6c3c5badba8bb3330fc527357ec0d296
Reviewed-on: https://go-review.googlesource.com/18648
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Fixes #13916.

Change-Id: If2cad5473a749460909519ac20aca19dea8a2e7a
Reviewed-on: https://go-review.googlesource.com/18671Reviewed-by: David Crawshaw <crawshaw@golang.org>

Fixes build.

Change-Id: Idd7d87f0bf3fe553b3ab00dd32eee4925a4fe3ff
Reviewed-on: https://go-review.googlesource.com/18647
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Change-Id: I6b1dc789e54a385c958961e7ba16bfd9d0f3b313
Reviewed-on: https://go-review.googlesource.com/18629Reviewed-by: Ian Lance Taylor <iant@golang.org>

Passes with go test -race -count=1000 -name=TestServerValidatesHostHeader now
without hanging.

Fixes #13950

Change-Id: I41c3a555c642595c95c8c52f19a05a4c68e67630
Reviewed-on: https://go-review.googlesource.com/18660
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This doesn't fix a bug, but may improve performance in programs that
have many concurrent calls from C to Go.  The old code made several
system calls between lockextra and unlockextra.  That could be happening
while another thread is spinning acquiring lockextra.  This changes the
code to not make any system calls while holding the lock.

Change-Id: I50576478e478670c3d6429ad4e1b7d80f98a19d8
Reviewed-on: https://go-review.googlesource.com/18548Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #12217.

Change-Id: I5ee6cb18eaa66bdec1affe689aa531c05e719fc9
Reviewed-on: https://go-review.googlesource.com/18645Reviewed-by: Andrew Gerrand <adg@golang.org>

TestFutexsleep is supposed to clean up before returning by waking up
the goroutines it started and left blocked in futex sleeps. However,
it currently fails at this in several ways:

1. Both the sleep and wakeup are done on the address of tt.mtx, but in
   both cases tt is a *local copy* of the futexsleepTest created by a
   loop, so the sleep and wakeup happen on completely different
   addresses. Fix this by making them both use the address of the
   global tt.mtx.

2. If the sleep happens after the wakeup (not likely, but not
   impossible), it won't wake up. Fix this by using the futex protocol
   properly: sleep if the mutex's value is 0, and set the mutex's
   value to non-zero before doing the wakeup.

3. If TestFutexsleep runs more than once, channels and mutex values
   left over from the first run will interfere with later runs. Fix
   this by clearing the mutex value and creating a new channel for
   each test and waiting for goroutines to finish before returning
   (lest they send their completion to the channel for the next run).

As an added bonus, this test now actually tests that futex
sleep/wakeup work. Previously this test would have been satisfied if
futexsleep was an infinite loop and futexwakeup was a no-op.

Change-Id: I1cbc6871cc9dcb8f4601b3621913bec2b79b0fc3
Reviewed-on: https://go-review.googlesource.com/18617Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>