On Windows, there is currently a race between unminit closing the
thread's handle and profileloop1 suspending the thread using its
handle. If another handle reuses the same handle value, this can lead
to unpredictable results.
To fix this, we protect the thread handle with a lock and duplicate it
under this lock in profileloop1 before using it.
This is going to become a much bigger problem with non-cooperative
preemption (#10958, #24543), which uses the same basic mechanism as
profileloop1.
Change-Id: I9d62b83051df8c03f3363344438e37781a69ce16
Reviewed-on: https://go-review.googlesource.com/c/go/+/207779
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This field is only used on Windows.
Change-Id: I12d4df09261f8e7ad54c2abd7beda669af28c8e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/207778
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Since the new page allocator, AIX's GDB has trouble running Go programs.
It does work but it can be really slow. Therefore, they are disable when
tests are run with -short.
Updates: #35710
Change-Id: Ibfc4bd2cd9714268f1fe172aaf32a73612e262d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/207919
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In CL 207962, I removed a seemingly-redundant -i flag. As it turns
out, the -i flag has *two* meanings: “install dependencies”, and “do
not actually run the test”. Without the flag, we omit the former
behavior, but add the latter.
We're about to run specific tests from these binaries on the very next
line, so don't preemptively run all of the tests.
Updates #30316
Change-Id: Ie3d8a37dc5f6bd98c232b308b0a6a165b5d82f7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/207966
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TestInstalls was already mostly redundant with
TestInstallInto{GOPATH,GOBIN}, except for one additional check for the
install location of cmd/fix.
We can't assume that GOROOT is writable in general, so we also can't
assume that the test will be able to reinstall cmd/fix at run time.
Moreover, other processes running in parallel may expect to invoke
cmd/fix themselves, so this test temporarily removing it could induce
systemwide flakes.
We could carefully construct a parallel GOROOT and install cmd/fix
into it, but we can get *almost* as much coverage — at a much lower
cost — by checking the output of 'go list' instead of actually
rebuilding and reinstalling the binary.
Updates #28387
Updates #30316
Change-Id: Id49f44a68b0c52dfabb84c665f63c4e7db58dd49
Reviewed-on: https://go-review.googlesource.com/c/go/+/207965
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Update gccgoPkgpathToSymbolNew() to bring it into conformance
with the way that gccgo now handles packagepaths with embedded
dots (see CL 200838). See also https://gcc.gnu.org/PR61880, a
related bug.
Updates #35623.
Change-Id: I32f064320b9af387fc17771530c745a9e3003c20
Reviewed-on: https://go-review.googlesource.com/c/go/+/207957
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These terms will be defined throughout the document, and more terms
will be added. After drafting a few sections, it's clear that a
glossary will be useful. There are enough terms that it would be
overwhelming at the beginning.
Also, add anchors for each heading and add a couple more headings.
Updates #33637
Change-Id: I0017064f0b1e5e656dd280018ca0379484345df1
Reviewed-on: https://go-review.googlesource.com/c/go/+/206478
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Tyler Bui-Palsulich <tbp@google.com>
The whole point of copying these files is so that we can modify them.
Updates #30316
Change-Id: Iaba7ddec5159078f2c3d3451cbab363365b15c9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/207963
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
At one point (before GOCACHE), the '-i' flag meant, effectively,
“save the intermediate results of this command to make
future commands faster”.
However, now that we require GOCACHE to be enabled everywhere, '-i' no
longer has that meaning: the intermediate results are already saved in
GOCACHE, so the -i flag merely adds extra work (copying or linking
things from GOCACHE into pkg), and also adds additional failure modes
resulting from that extra work (particularly when 'pkg' is read-only).
Since the flag now causes more harm than good, omit it.
Updates #30316
Change-Id: I295b6c0fc460dfc11ffa2a964cbb2a40f2935edc
Reviewed-on: https://go-review.googlesource.com/c/go/+/207962
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This test runs 'go test -race -i runtime/race' and checks that it did
not overwrite cmd/cgo.
If GOROOT/pkg is read-only and GOROOT/pkg/$GOOS_$GOARCH_race is not
already populated, as are the conditions if the Go toolchain was
installed from source as root using 'make.bash', then 'go test -race
-i' itself will fail because it cannot install packages to GOROOT/pkg.
However, such a failure is not relevant to the test: even if 'go test
-race -i' fails, we can still verify that it did not incidentally
overwrite cmd/cgo.
Updates #28387
Updates #30316
Change-Id: Iff2f75a0aeb4c926290ac3062c83695604522078
Reviewed-on: https://go-review.googlesource.com/c/go/+/207959
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The darwin-arm64-correlium builder was failing the test consistently
at the old values. Give the ticks more time to let the test pass.
Updates #35692
Change-Id: Ibc636cd4db2595c82f4e8c6c822c3df4c2b7e0a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/207839
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Handle immediates larger than 12-bits by rewriting as an LUI instruction with
the high bits, followed by the original instruction with the low bits.
Based on the riscv-go port.
Updates #27532
Change-Id: I8ed6d6e6db06fb8a27f3ab75f467ec2b7ff1f075
Reviewed-on: https://go-review.googlesource.com/c/go/+/204626
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Dan Scales pointed out a theoretical deadlock in the runtime.
The timer code runs timer functions while holding the timers lock for a P.
The scavenger queues up a timer function that calls wakeScavenger,
which acquires the scavenger lock.
The scavengeSleep function acquires the scavenger lock,
then calls resetTimer which can call addInitializedTimer
which acquires the timers lock for the current P.
So there is a potential deadlock, in that the scavenger lock and
the timers lock for some P may both be acquired in different order.
It's not clear to me whether this deadlock can ever actually occur.
Issue 35532 describes another possible deadlock.
The pollSetDeadline function acquires pd.lock for some poll descriptor,
and in some cases calls resettimer which can in some cases acquire
the timers lock for the current P.
The timer code runs timer functions while holding the timers lock for a P.
The timer function for poll descriptors winds up in netpolldeadlineimpl
which acquires pd.lock.
So again there is a potential deadlock, in that the pd lock for some
poll descriptor and the timers lock for some P may both be acquired in
different order. I think this can happen if we change the deadline
for a network connection exactly as the former deadline expires.
Looking at the code, I don't see any reason why we have to hold
the timers lock while running a timer function.
This CL implements that change.
Updates #6239
Updates #27707Fixes#35532
Change-Id: I17792f5a0120e01ea07cf1b2de8434d5c10704dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/207348
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Take the opportunity of deflaking to make it take less time to run.
Updates #35537
Change-Id: I91ca8094fbe18fbfcd34dfda98da1592c9c82943
Reviewed-on: https://go-review.googlesource.com/c/go/+/207403
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This will help to detect regressions of #28387 when running
'go test cmd/go' in a writable GOROOT.
Updates #28387
Updates #30316
Change-Id: I551e044111535404688b1a76e63163dfcb41bb5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/207701
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The old recipe for making an infinite loop not be infinite
in the debugger could create an instruction (Prog) with a
line number not tied to any file (index == 0). This caused
downstream failures in DWARF processing.
So don't do that. Also adds a test, also adds a check+panic
to ensure that the next time this happens the error is less
mystifying.
Fixes#35652
Change-Id: I04f30bc94fdc4aef20dd9130561303ff84fd945e
Reviewed-on: https://go-review.googlesource.com/c/go/+/207613
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
It was attempting to write a test binary to the working directory.
Updates #28387
Updates #30316
Change-Id: I82eca3a8a3e019dc6dacbe1f02a0583577694b93
Reviewed-on: https://go-review.googlesource.com/c/go/+/207614
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also convert associated tests of GOPATH and 'go install' so that we
can remove the corresponding source file from testdata/src.
Updates #28387
Updates #30316
Change-Id: Id8c2fde4dc88954b29aefe71c9fa7e974a2ca932
Reviewed-on: https://go-review.googlesource.com/c/go/+/207605
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
I'm hoping to eliminate testdata/src/go-cmd-test, so porting over
tests that assume its existence.
Updates #28387
Updates #30316
Change-Id: I20bae780a4eb87cc19cc1e8531b84ab4a8a3c255
Reviewed-on: https://go-review.googlesource.com/c/go/+/207608
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
These tests were all attempting to write to their working directory,
which may fail if GOROOT is read-only.
Updates #28387
Updates #30316
Change-Id: Ib85234cdcf5ef4d554d8c99cf0942981bbd394ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/207604
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
When initializing an M, we set up its signal stack to the gsignal
stack if an alternate signal stack is not already set. On Android,
an alternate signal stack is always set, even cgo is not used.
This breaks the logic of saving/fetching G on the signal stack
during VDSO, which assumes the signal stack is allocated by Go if
cgo is not used (if cgo is used, we use TLS for saving G).
When cgo is not used, we can always use the Go signal stack, even
if an alternate signal stack is already set. Since cgo is not
used, no one other than the Go runtime will care.
Fixes#35554.
Change-Id: Ia9d84cd55cb35097f3df46f37996589c86f10e0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/207445
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
tabs.getSelected has been deprecated since Chrome 33. Instead,
use tabs.query.
Fixes#35663
Change-Id: I4f7f17f948987aff8409ac8210f04eb1f7ebf908
Reviewed-on: https://go-review.googlesource.com/c/go/+/207402
Reviewed-by: Andrew Bonventre <andybons@golang.org>
This reverts CL 207477, restoring CL 207352 with a fix for the
regression observed in the Windows builders.
cmd/compile evidently does not fully support NUL as an output on
Windows, so this time we write ignored 'compile' outputs
to temporary files (instead of os.DevNull as in CL 207352).
Updates #28387Fixes#35619
Change-Id: I2edc5727c3738fa1bccb4b74e50d114cf2a7fcff
Reviewed-on: https://go-review.googlesource.com/c/go/+/207602
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 206078 introduced a stray errno check that was always false. This CL removes it.
Updates #35276
Change-Id: I6996bb595d347fe81752786a3d83d3432735c9cb
GitHub-Last-Rev: e026e71b16
GitHub-Pull-Request: golang/go#35650
Reviewed-on: https://go-review.googlesource.com/c/go/+/207577
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This allows maphash.Hash to be allocated on the stack for typical uses.
Fixes#35636
Change-Id: I8366507d26ea717f47a9fb46d3bd69ba799845ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/207444
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
On AIX, addresses returned by mmap are between 0x0a00000000000000
and 0x0afffffffffffff. The previous solution to handle these large
addresses was to increase the arena size up to 60 bits addresses,
cf CL 138736.
However, with the new page allocator, the 60bit heap addresses are
causing huge memory allocations, especially by (s *pageAlloc).init. mmap
and munmap syscalls dealing with these allocations are reducing
performances of every Go programs.
In order to avoid these allocations, arenaBaseOffset is set to
0x0a00000000000000 and heap addresses are on 48bit, as others operating
systems.
Updates: #35451
Change-Id: Ice916b8578f76703428ec12a82024147a7592bc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/206841
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The test is inherently slightly flaky, so repeat to reduce flakiness.
Fixes#35537
Change-Id: Id918d48d33c7d5e19c4f24df104adc7fbf3720f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/207457
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When we run tests, we may need to write the test binary (and/or test
variants of its dependencies) to GOCACHE. (This also fixes several
test cases in cmd/go, which preserves the GOCACHE variable for
efficiency.)
It is highly unlikely that tests will try to modify .git, and that
directory contains many files, so don't bother with it.
Updates #30316
Change-Id: Id11136c6c64d8f0afc6c6ba5d94c9269df231052
Reviewed-on: https://go-review.googlesource.com/c/go/+/207441
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 205340 changed the linker to skip certain flags when linking
for iOS. However, for host linking on iOS (such as on the Corellium
darwin/arm64 builders) the MachO platform defaults to PLATFORM_MACOS,
and the flags are not skipped.
Avoids warnings such as
ld: warning: -no_pie ignored for arm64
Updates #32963
Change-Id: Ib6b4c2375fd14cf89410bf5ff1537b692b7a1c15
Reviewed-on: https://go-review.googlesource.com/c/go/+/206337
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
While running various tests for #28387, I keep ending up with an
unwritable GOROOT after a failure.
While the unwritable GOROOT is a fairly exotic condition (normally
only happens on builders), it's somewhat annoying when debugging, so
I'm switching all of the log.Fatal* call sites to use the existing
fatalf function, which supports general atexit-like cleanup.
Updates #28387
Change-Id: I473cda7eacd9ad82bdeab647766373126dc7390e
Reviewed-on: https://go-review.googlesource.com/c/go/+/207341
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
