Fixes #13701.

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

Fixes #13704.

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

This change replaces the existing log format separated by commas and
spaces with space-separated one.

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

Approved by the IETF.

https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/

Change-Id: I688597bb5f7ef7c7a9be660a4fcd2ef02d9dc9f4
Reviewed-on: https://go-review.googlesource.com/18112Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David Symonds <dsymonds@golang.org>

Change-Id: Ic3f006f86a86de628e14b107f88a5923ea856a58
Reviewed-on: https://go-review.googlesource.com/18093Reviewed-by: David Symonds <dsymonds@golang.org>

Fixes #13684.

Change-Id: I3977119b6eb1d6b7dc2ea1e7d6656a8f0d421bc1
Reviewed-on: https://go-review.googlesource.com/18060
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

In general the package net deals IPv4 addresses as IPv6 IPv4-mapped
addresses internally for the dual stack era, when we need to support
various techniques on IPv4/IPv6 translation.

This change makes windows implementation follow the same pattern which
BSD variants and Linux do.

Updates #13544.

Also fixes an unintentionally formatted line by accident by gofmt.

Change-Id: I4953796e751fd8050c73094468a0d7b0d33f5516
Reviewed-on: https://go-review.googlesource.com/17992Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

CL skips interfaces that are not listed on getmac output.

Fixes #13606

Change-Id: Ic25c9dc95e8eeff4d84b78e99131a4f97020164c
Reviewed-on: https://go-review.googlesource.com/17994Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>

Fixes #13690.

Change-Id: I3b9b993a2e7ecf07bab7d1935d4c83a86bc6ba3a
Reviewed-on: https://go-review.googlesource.com/18054Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

Only install signal handlers for synchronous signals that become
run-time panics.  Set the SA_ONSTACK flag for other signal handlers as
needed.

Fixes #13028.
Update #12465.
Update #13034.
Update #13042.

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

Reapply golang.org/cl/17918

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

It turns out that the second argument for sigaction on Darwin has a
different type than the first argument.  The second argument is the user
visible sigaction struct, and does not have the sa_tramp field.

I base this on
  http://www.opensource.apple.com/source/Libc/Libc-1081.1.3/sys/sigaction.c
not to mention actual testing.

While I was at it I removed a useless memclr in setsig, a relic of the C
code.

This CL is Darwin-specific changes.  The tests for this CL are in
https://golang.org/cl/17903 .

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

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

Fixes #13681.

Change-Id: I308930f4d9200fbe0f09cd08c38392ca1bb0db67
Reviewed-on: https://go-review.googlesource.com/18044Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Programs that call panic to crash after detecting a serious problem
may wish to use SetTraceback to force printing of all goroutines first.

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

This future-proofs the Chdr64 structure against later versions of ELF
defining this field and declutters the documentation without changing
the layout of the struct.

This structure does not exist in the current release, so this change
is safe.

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

Fixes #13683.

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

Fixes #13671

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

Copy the same sentence from Transport.TLSNextProto.

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

Fixes #11407.

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

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

Currently, if sigprof determines that the G is in user code (not cgo
or libcall code), it will only traceback the G stack if it can acquire
the stack barrier lock. However, it has no such restriction if the G
is in cgo or libcall code. Because cgo calls count as syscalls, stack
scanning and stack barrier installation can occur during a cgo call,
which means sigprof could attempt to traceback a G in a cgo call while
scanstack is installing stack barriers in that G's stack. As a result,
the following sequence of events can cause the sigprof traceback to
panic with "missed stack barrier":

1. M1: G1 performs a Cgo call (which, on Windows, is any system call,
   which could explain why this is easier to reproduce on Windows).

2. M1: The Cgo call puts G1 into _Gsyscall state.

3. M2: GC starts a scan of G1's stack. It puts G1 in to _Gscansyscall
   and acquires the stack barrier lock.

4. M3: A profiling signal comes in. On Windows this is a global
   (though I don't think this matters), so the runtime stops M1 and
   calls sigprof for G1.

5. M3: sigprof fails to acquire the stack barrier lock (because the
   GC's stack scan holds it).

6. M3: sigprof observes that G1 is in a Cgo call, so it calls
   gentraceback on G1 with its Cgo transition point.

7. M3: gentraceback on G1 grabs the currently empty g.stkbar slice.

8. M2: GC finishes scanning G1's stack and installing stack barriers.

9. M3: gentraceback encounters one of the just-installed stack
   barriers and panics.

This commit fixes this by only allowing cgo tracebacks if sigprof can
acquire the stack barrier lock, just like in the regular user
traceback case.

For good measure, we put the same constraint on libcall tracebacks.
This case is probably already safe because, unlike cgo calls, libcalls
leave the G in _Grunning and prevent reaching a safe point, so
scanstack cannot run during a libcall. However, this also means that
sigprof will always acquire the stack barrier lock without contention,
so there's no cost to adding this constraint to libcall tracebacks.

Fixes #12528. For 1.5.3 (will require some backporting).

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

Currently, setNextBarrierPC manipulates the stack barriers without
acquiring the stack barrier lock. This is mostly okay because
setNextBarrierPC also runs synchronously on the G and prevents safe
points, but this doesn't prevent a sigprof from occurring during a
setNextBarrierPC and performing a traceback.

Given that setNextBarrierPC simply sets one entry in the stack barrier
array, this is almost certainly safe in reality. However, given that
this depends on a subtle argument, which may not hold in the future,
and that setNextBarrierPC almost never happens, making it nowhere near
performance-critical, we can simply acquire the stack barrier lock and
be sure that the synchronization will work.

Updates #12528. For 1.5.3.

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

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

Update #12416.

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

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

Change-Id: Ic4f4bc7ea7478908716b951815280e394c55310b
Reviewed-on: https://go-review.googlesource.com/17975Reviewed-by: Robert Griesemer <gri@golang.org>

Change-Id: If2b30ab412d6799c8be01eb007462d6b58660ece
Reviewed-on: https://go-review.googlesource.com/18014Reviewed-by: Chris Broadfoot <cbro@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

(Found while debugging release problems with go1.6beta1)

Updates #12002

Change-Id: Iec197a754205e7fd28be154f27f17f3315886364
Reviewed-on: https://go-review.googlesource.com/18011Reviewed-by: Chris Broadfoot <cbro@golang.org>

Change-Id: Iae05082530891175e9c86da244e610bc92759561
Reviewed-on: https://go-review.googlesource.com/17918Reviewed-by: Chris Broadfoot <cbro@golang.org>

Fixes #13660

Change-Id: I05bcb4efcb865192a1ef6756e9dccef83505934c
Reviewed-on: https://go-review.googlesource.com/17990Reviewed-by: Chris Broadfoot <cbro@golang.org>

Update docs on ResponseWriter and Handler around concurrency.

Also add a test.

The Handler docs were old and used "object" a lot. It was also too
ServeMux-centric.

Fixes #13050
Updates #13659 (new issue found in http2 while writing the test)

Change-Id: I25f53d5fa54f1c9d579d3d0f191bf3d94b1a251b
Reviewed-on: https://go-review.googlesource.com/17982Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

The test for non-package main top-level inputs is done while parsing
the export data. Issue #13468 happened because we were not parsing
the export data when using compiler-generated archives
(that is, when using go tool compile -pack).

Fix this by parsing the export data even for archives.

However, that turns up a different problem: the export data check
reports (one assumes spurious) skew errors now, because it has
not been run since Go 1.2.
(Go 1.3 was the first release to use go tool compile -pack.)

Since the code hasn't run since Go 1.2, it can't be that important.
Since it doesn't work today, just delete it.

Figuring out how to make this code work with Robert's export
format was one of the largest remaining TODOs for that format.
Now we don't have to.

Fixes #13468 and makes the world a better place.

Change-Id: I40a4b284cf140d49d48b714bd80762d6889acdb9
Reviewed-on: https://go-review.googlesource.com/17976Reviewed-by: Robert Griesemer <gri@golang.org>

Since we allow non-200 responses from HTTPS in normal operation,
it seems odd to reject them in -insecure operation.

Fixes #13037 (again).

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

The change here is to move the closeBody call into the if block.
The logging adjustments are just arranging to tell the truth:
in particular if we're not in insecure mode and we get a non-200
error then we do not actually ignore the response
(except as caused by closing the body incorrectly).

As the comment below the change indicates, it is intentional that
we process non-200 pages. The code does process them, because
the if err != nil || status != 200 block does not return.
But that block does close the body, which depending on timing
can apparently poison the later read from the body.

See #13037's initial report:

	$ go get -v bosun.org/cmd/bosun/cache
	Fetching https://bosun.org/cmd/bosun/cache?go-get=1
	ignoring https fetch with status code 404
	Parsing meta tags from https://bosun.org/cmd/bosun/cache?go-get=1 (status code 404)
	import "bosun.org/cmd/bosun/cache": parsing bosun.org/cmd/bosun/cache: http: read on closed response body
	package bosun.org/cmd/bosun/cache: unrecognized import path "bosun.org/cmd/bosun/cache"

The log print about ignoring the https fetch is not strictly true,
since the next thing that happened was parsing the body of that fetch.
But the read on the closed response body failed during parsing.

Moving the closeBody to happen only when we're about to discard the
result and start over (that is, only in -insecure mode) fixes the parse.

At least it should fix the parse. I can't seem to break the parse anymore,
because of #13648 (close not barring future reads anymore),
but this way is clearly better than the old way. If nothing else the old code
closed the body twice when err != nil and -insecure was not given.

Fixes #13037.

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

This caused #13657.
Reverting fixes #13657.

I was trying to be helpful by fixing #12313,
but I don't need the fix myself.
Will leave for someone with more motivation.

This reverts commit 3e9f0636.

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

Fixes #11207

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

Patch from Russ.

No bug identified, but I didn't search exhaustively. The new code is
easier to read.

Fixes #13621

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

Thanks to @toxeus on GitHub for the test case.

Fixes #12612.

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

Updates to golang.org/x/net/http2 git rev 28273ec9 for
https://golang.org/cl/17937

Fixes #13648

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