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>
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/34565
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
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>
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>
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/34390
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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/34507
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
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>
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>
In Go 1.8, almost all the platforms except NaCl provide network
interface and address identification and applications can use IPv4
limited or directed broadcast addresses appropriately.
Fixes#18176.
Change-Id: Ie5de834d19c0aaeb4128a3ca655f6c4c9ae5e501
Reviewed-on: https://go-review.googlesource.com/34435
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Search the sample types in the profile being processed to map
sample type options to indices in the profile sample type array.
Previously these were hardcoded, which caused issues when the
sample types for a profile type changed. For instance, this was
triggered by the native generation of profiles in profile.proto
format.
This fixes#18230. A similar mechanism already exists on the upstream
pprof.
Change-Id: I945d8d842a0c2ca14299dabefe83124746ecd7e2
Reviewed-on: https://go-review.googlesource.com/34382
Reviewed-by: Michael Matloob <matloob@golang.org>
This change replaces the remaining use of "mask" with "prefix length"
and uses IPv4 reserved address blocks for documentation.
UPdates #15228.
Updates #18175.
Change-Id: I56c4f1205821c64f3195b023ad515b9d54e33f64
Reviewed-on: https://go-review.googlesource.com/34431
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We are seeing a bad stack map in #18190. In a copystack, it is
mistaking a slot for a pointer.
Presumably this is caused either by our fledgling dynlink support on
darwin, or a consequence of having two copies of the runtime in the
process. But I have been unable to work out which in the 1.8 window,
so pushing darwin support to 1.9 or later.
Change-Id: I7fa4d2dede75033d9a428f24c1837a4613bd2639
Reviewed-on: https://go-review.googlesource.com/34391
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I meant to say ~7, instead of ^7, in the review.
Fix build.
Change-Id: I5060bbcd98b4ab6f00251fdb68b6b35767e5acf1
Reviewed-on: https://go-review.googlesource.com/34411
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I00c97c36e8fdc79582eaed21877e4c8f44568666
Reviewed-on: https://go-review.googlesource.com/34316
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
