Return a meaningful message when a profile is empty.
Also rename "IO blocking" to "Network blocking",
currently only network blocking is captured.

Fixes #11098

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

There were two issues.
1. Delayed EvGoSysExit could have been emitted during TraceStart,
while it had not yet emitted EvGoInSyscall.
2. Delayed EvGoSysExit could have been emitted during next tracing session.

Fixes #10476
Fixes #11262

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

All the other error messages in this package are "lzw: etc".

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

In preparation for rename of cgocall_errno into cgocall and
asmcgocall_errno into asmcgocall in the fllowinng CL.
rsc requested CL 9387 to be split into two parts. This is first part.

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

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

Work-around issue #11265 and re-enable tests for Plan9.

Change-Id: I3aabb674a149b8eb936f948dd4cda5fd81454646
Reviewed-on: https://go-review.googlesource.com/11194
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Replace custom solution with new (internal) library call.

Change-Id: I53b26a1caf0684b9f5d8d749b10d9f3ba18a3001
Reviewed-on: https://go-review.googlesource.com/11193Reviewed-by: Damien Neil <dneil@google.com>

Change-Id: I0e1aab2fe2340a1fbb7f377dbd7a72ea6f0477d8
Reviewed-on: https://go-review.googlesource.com/11153Reviewed-by: Alan Donovan <adonovan@google.com>

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

This change will brake the build. The immediately following change
contains the necessary adjustments to make it work again. We're
doing this in two steps to expose the manual changes applied.

Change-Id: I225947da23e190b12e12cbd0c5e6e91628de7f53
Reviewed-on: https://go-review.googlesource.com/11151Reviewed-by: Alan Donovan <adonovan@google.com>

Change-Id: I376ff39594b532a5490f13e3985b7a6ff4b6761d
Reviewed-on: https://go-review.googlesource.com/11191Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

Change-Id: I389b2e10fe667eaa55f87b71b1e004994694d4a3
Reviewed-on: https://go-review.googlesource.com/11173Reviewed-by: Austin Clements <austin@google.com>

Updates #11241

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

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

This fixes a hang during runtime.TestTraceStress.
It also fixes double-scan of stacks, which leads to
stack barrier installation failures.

Both of these have shown up as flaky failures on the dashboard.

Fixes #10941.

Change-Id: Ia2a5991ce2c9f43ba06ae1c7032f7c898dc990e0
Reviewed-on: https://go-review.googlesource.com/11089Reviewed-by: Austin Clements <austin@google.com>

Adjust timestamps in TestABIChecking to make sure that the library and
executable are rebuilt when expected.

Change-Id: I3288c254ba8201b5b4255347b0cb056fa0908657
Reviewed-on: https://go-review.googlesource.com/11128Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

//go:systemstack means that the function must run on the system stack.

Add one use in runtime as a demonstration.

Fixes #9174.

Change-Id: I8d4a509cb313541426157da703f1c022e964ace4
Reviewed-on: https://go-review.googlesource.com/10840Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>

Change-Id: I750900e0aed9ec528fea3f442c35196773e3ba5e
Reviewed-on: https://go-review.googlesource.com/11163Reviewed-by: Minux Ma <minux@golang.org>

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

I updated some references to 6g, 6l and friends that I came across, as those
programs don't exist anymore. I also fixed some echos in make.rc to match other make.* scripts while I was there.

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

Corrected several issues:
 * RFC1951 section 3.2.7 dictates that it is okay for the HDist tree to have a
single code of zero bits. Furthermore, the behavior of the C zlib library
permits empty trees even when there are more than one codes.
 * RFC1951 section 3.2.5 shows that HLit codes 286 and 287 are invalid. Thus,
Go's implementation should choke on inputs using these codes.
 * RFC1951 section 3.2.5 and 3.2.7 are ambiguous about whether the number of
HDist codes can be greater than 30. The C zlib library (which is the canonical
reference implementation) performs this check here:
https://github.com/madler/zlib/blob/62d6112a7981ad7c34f3b43cffdf00d4662a4f25/inflate.c#L906

In addition, a number of test cases were added to the unit tests that exercises
these edge cases. The test cases listed in TestStreams will either fail or
succeed in a manner matching the behaviour of the C zlib version. Given that the
C zlib implementation is the reference for the world, Go's implementation should
match C zlib behaviour.

Fixes #11030

Change-Id: Ic24e4e40ce5832c7e1930249246e86d34bfedaa6
Reviewed-on: https://go-review.googlesource.com/11000Reviewed-by: Nigel Tao <nigeltao@golang.org>

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

Also modified test/run.go to ignore messages prefixed <autogenerated>
because those cannot be described with "// ERROR ...", and backed out
patch from issue #9537 because it is no longer necessary.  The reasons
described in the 9537 discussion for why escape analysis cannot run
late no longer hold, happily.

Fixes #11053.

Change-Id: Icb14eccdf2e8cde3d0f8fb8a216b765400a96385
Reviewed-on: https://go-review.googlesource.com/11088Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>

This change reintroduces CL 8523. CL 8523 was reverted because
it broke darwin and netbsd builds. Now that this test is part
of "go tool dist test" command we could skip OSes that fail.

Updates #10360

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

So the tests don't interfere with each other on windows.

Fixes #11217

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

This change allows LookupAddr to use getnameinfo through cgo for working
together with various name services other than DNS.

Fixes #7855.

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

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

This flag is not needed in the std repo because we don't have
tests requiring it. Remove it before it's frozen into the API.

Change-Id: I18b861eea146ad67e7a3c26ee8be681d8065ef12
Reviewed-on: https://go-review.googlesource.com/11150Reviewed-by: Alan Donovan <adonovan@google.com>

This makes the behaviour match what happens when duplicate symbols are read
from regular object files and fixes errors about cgoAlwaysFalse when linking
an executable that uses cgo against a shared library.

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

TestHostname was re-enabled in CL 10753.
However, on Plan 9 the hostname is not obtained
by executing a "hostname" command, but by reading
the #c/sysname file.

Change-Id: I80c0e303f4983fe39ceb300ad64e2c4a8392b695
Reviewed-on: https://go-review.googlesource.com/11033
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Currently, when shrinkstack computes whether the halved stack
allocation will have enough room for the stack, it accounts for the
stack space that's actively in use but fails to leave extra room for
the stack guard space. As a result, *if* the minimum stack size is
small enough or the guard large enough, it may shrink the stack and
leave less than enough room to run nosplit functions. If the next
function called after the stack shrink is a nosplit function, it may
overflow the stack without noticing and overwrite non-stack memory.

We don't think this is happening under normal conditions right now.
The minimum stack allocation is 2K and the guard is 640 bytes. The
"worst case" stack shrink is from 4K (4048 bytes after stack barrier
array reservation) to 2K (2016 bytes after stack barrier array
reservation), which means the largest "used" size that will qualify
for shrinking is 4048/4 - 8 = 1004 bytes. After copying, that leaves
2016 - 1004 = 1012 bytes of available stack, which is significantly
more than the guard space.

If we were to reduce the minimum stack size to 1K or raise the guard
space above 1012 bytes, the logic in shrinkstack would no longer leave
enough space.

It's also possible to trigger this problem by setting
firstStackBarrierOffset to 0, which puts stack barriers in a debug
mode that steals away *half* of the stack for the stack barrier array
reservation. Then, the largest "used" size that qualifies for
shrinking is (4096/2)/4 - 8 = 504 bytes. After copying, that leaves
(2096/2) - 504 = 8 bytes of available stack; much less than the
required guard space. This causes failures like those in issue #11027
because func gc() shrinks its own stack and then immediately calls
casgstatus (a nosplit function), which overflows the stack and
overwrites a free list pointer in the neighboring span. However, since
this seems to require the special debug mode, we don't think it's
responsible for issue #11027.

To forestall all of these subtle issues, this commit modifies
shrinkstack to correctly account for the guard space when considering
whether to halve the stack allocation.

Change-Id: I7312584addc63b5bfe55cc384a1012f6181f1b9d
Reviewed-on: https://go-review.googlesource.com/10714Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Issues #10240, #10541, #10941, #11023, #11027 and possibly others are
indicating memory corruption in the runtime. One of the easiest places
to both get corruption and detect it is in the allocator's free lists
since they appear throughout memory and follow strict invariants. This
commit adds a check when sweeping a span that its free list is sane
and, if not, it prints the corrupted free list and panics. Hopefully
this will help us collect more information on these failures.

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

Change-Id: I401ce8d612160a4f4ee617bddca6827fa544763a
Reviewed-on: https://go-review.googlesource.com/11087Reviewed-by: Austin Clements <austin@google.com>

Change-Id: I2cd58a665d9df26583128c633c443325dcc3f288
Reviewed-on: https://go-review.googlesource.com/11131Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: I7b54be9d8b50b39e01c6be21f310ae9a10404e9d
Reviewed-on: https://go-review.googlesource.com/10753Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The motivation of TestLookupHost was to test codepaths on LookupHost,
LookupIP when we set CGO_ENABLED=1. Now we have serveral tests on those
APIs and their codepaths such as TestLookupGooglePublicDNSAddr,
TestCgoLookupIP, TestGoLookupIP, and the test using the ambiguous source
"localhost" is unnecessary.

Fixes #11182.

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

Sadly examples cannot use the new internal/testenv, so this is
extends the crude build tag restriction in this file.

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

Unfortunately there's no simple, easy way to make Dial{TCP,UDP} fail
consistently across all platforms. Fow now we skip the test on Solaris.

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

Fixes #10683.

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