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/11151
Reviewed-by: Alan Donovan <adonovan@google.com>
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/11089
Reviewed-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/11128
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@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/10840
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
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/11162
Reviewed-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:
62d6112a79/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/11000
Reviewed-by: Nigel Tao <nigeltao@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/11088
Reviewed-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/11119
Reviewed-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/11138
Reviewed-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/3420
Reviewed-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/11150
Reviewed-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/11117
Reviewed-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/10714
Reviewed-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/10713
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
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/11057
Reviewed-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/11086
Reviewed-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/11058
Reviewed-by: Ian Lance Taylor <iant@golang.org>
dialSerial connects to a list of addresses in sequence. If a
timeout is specified, then each address gets an equal fraction of the
remaining time, with a magic constant (2 seconds) to prevent
"dial a million addresses" from allotting zero time to each.
Normally, net.Dial passes the DNS stub resolver's output to dialSerial.
If an error occurs (like destination/port unreachable), it quickly skips
to the next address, but a blackhole in the network will cause the
connection to hang until the timeout elapses. This is how UNIXy clients
traditionally behave, and is usually sufficient for non-broken networks.
The DualStack flag enables dialParallel, which implements Happy Eyeballs
by racing two dialSerial goroutines, giving the preferred family a
head start (300ms by default). This allows clients to avoid long
timeouts when the network blackholes IPv4 xor IPv6.
Fixes#8453Fixes#8455Fixes#8847
Change-Id: Ie415809c9226a1f7342b0217dcdd8f224ae19058
Reviewed-on: https://go-review.googlesource.com/8768
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change-Id: Id93b8ab42fa311ce32209734ec9a0813f8736e25
Reviewed-on: https://go-review.googlesource.com/9914
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The main change is:
golang.org/cl/10800 add pos parameter to Eval; remove New, EvalNode
followed by several cleanups/follow-up fixes:
golang.org/cl/10992 remove global vars in test
golang.org/cl/10994 remove unused scope parameter from NewSignature
golang.org/cl/10995 provide full source file extent to file scope
golang.org/cl/10996 comment fix in resolver.go
golang.org/cl/11004 updated cmd/vet
golang.org/cl/11042 be robust in the presence of incorrect/missing position info
Fixes#9980.
Change-Id: Id4aff688f6a399f76bf92b84c7e793b8da8baa48
Reviewed-on: https://go-review.googlesource.com/11122
Reviewed-by: Alan Donovan <adonovan@google.com>
The problem was not the kernel version as I thought before, it was
that the test used the same number for both the UID and the GID.
Thanks to Chris Siebenmann for debugging this.
Fixes#11220.
Change-Id: Ib5077e182497155e84044683209590ee0f7c9dde
Reviewed-on: https://go-review.googlesource.com/11124
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This CL adds a very long comment explaining how isStale and
the new build IDs work. As part of writing the comment I realized:
// When the go command makes the wrong build decision and does not
// rebuild something it should, users fall back to adding the -a flag.
// Any common use of the -a flag should be considered prima facie evidence
// that isStale is returning an incorrect false result in some important case.
// Bugs reported in the behavior of -a itself should prompt the question
// ``Why is -a being used at all? What bug does that indicate?''
The two uses of -a that are most commonly mentioned in bugs filed
against the go command are:
go install -a ./...
go build -tags netgo -a myprog
Both of these commands now do the right thing without needing -a.
The -a exception we introduced in Go 1.4 was for the first form, and
it broke the second form. Again, neither needs -a anymore, so restore
the old, simpler, easier to explain, less surprising meaning used in Go 1.3:
if -a is given, rebuild EVERYTHING.
See the comment for more justification and history.
Summary of recent CLs (to link bugs to this one):
Fixes#3036. Now 'go install ./...' works.
Fixes#6534. Now 'go install ./...' works.
Fixes#8290. Now 'go install ./...' works.
Fixes#9369. Now 'go build -tags netgo myprog' works.
Fixes#10702. Now using one GOPATH with Go 1.5 and Go 1.6 works.
(Each time you switch, everything needed gets rebuilt.
Switching from Go 1.4 to Go 1.5 will rebuild properly.
Switching from Go 1.5 back to Go 1.4 still needs -a when
invoking the Go 1.4 go command.)
Change-Id: I19f9eb5286efaa50de7c8326602e94604ab572eb
Reviewed-on: https://go-review.googlesource.com/10761
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This causes packages and binaries built by Go 1.5 to look
out of date to Go 1.6 and vice versa, so that when you flip
between different Go versions but keep the same GOPATH,
the right rebuilding happens at each flip.
Go 1.4 binaries will also look out of date to Go 1.5,
but Go 1.5 binaries will not look out of date to Go 1.4
(since Go 1.4 doesn't have anything like this).
People flipping between Go 1.4 and Go 1.5 will still
need to use go install -a every time to flip to Go 1.4,
but not when they flip back to Go 1.5.
Fixes#6534.
Fixes#10702.
Change-Id: I0ae7f268f822d483059a938a4f22846ff9275b4c
Reviewed-on: https://go-review.googlesource.com/10760
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
A workaround for #10460.
Change-Id: I607a556561d509db6de047892f886fb565513895
Reviewed-on: https://go-review.googlesource.com/10819
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Fixes#11131
When running 'go install -buildmode=c-shared', under the circumstances
described in issue #11131, the install command would fail trying to
install cgo headers if they have already been installed (by a previous
call to 'go install -buildmode=c-shared').
Since it's safe to overwrite said headers (according to iant@), this CL
introduces a parameter to builder's 'copy' and 'move' functions that,
if set to 'true', would force the overwriting of already installed
files.
This parameter value is set to 'true' only when installing cgo headers,
for now.
Change-Id: I5bda17ee757066a8e5d2b39f2e8f3a389eb1e4a2
Reviewed-on: https://go-review.googlesource.com/10870
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The number of CPUs is of value when benchmarking but mostly
noise when testing. The recent change to default to the number
of CPUs available has made the tests noisier and confusing.
Fixes#11200
Change-Id: Ifc87d9ccb4177d73e304fb7ffcef4367bd163c9e
Reviewed-on: https://go-review.googlesource.com/11121
Reviewed-by: Russ Cox <rsc@golang.org>
While we're here, update the documentation and delete variables with no effect.
Change-Id: I4df0d266dff880df61b488ed547c2870205862f0
Reviewed-on: https://go-review.googlesource.com/10790
Reviewed-by: Austin Clements <austin@google.com>
A send on an unbuffered channel to a blocked receiver is the only
case in the runtime where one goroutine writes directly to the stack
of another. The garbage collector assumes that if a goroutine is
blocked, its stack contains no new pointers since the last time it ran.
The send on an unbuffered channel violates this, so it needs an
explicit write barrier. It has an explicit write barrier, but not one that
can handle a write to another stack. Use one that can (based on type bitmap
instead of heap bitmap).
To make this work, raise the limit for type bitmaps so that they are
used for all types up to 64 kB in size (256 bytes of bitmap).
(The runtime already imposes a limit of 64 kB for a channel element size.)
I have been unable to reproduce this problem in a simple test program.
Could help #11035.
Change-Id: I06ad994032d8cff3438c9b3eaa8d853915128af5
Reviewed-on: https://go-review.googlesource.com/10815
Reviewed-by: Austin Clements <austin@google.com>
