Adding the evconst(n) call for OANDAND and OOROR in
golang.org/cl/18262 was originally just to parallel the above iscmp
branch, but upon further inspection it seemed odd that removing it
caused test/fixedbugs/issue6671.go's
var b mybool
// ...
b = bool(true) && true // ERROR "cannot use"
to start failing (i.e., by not emitting the expected "cannot use"
error).
The problem is that evconst(n)'s settrue and setfalse paths always
reset n.Type to idealbool, even for logical operators where n.Type
should preserve the operand type. Adding the evconst(n) call for
OANDAND/OOROR inadvertantly worked around this by turning the later
evconst(n) call at line 2167 into a noop, so the "n.Type = t"
assignment at line 739 would preserve the operand type.
However, that means evconst(n) was still clobbering n.Type for ONOT,
so declarations like:
const _ bool = !mybool(true)
were erroneously accepted.
Update #13821.
Change-Id: I18e37287f05398fdaeecc0f0d23984e244f025da
Reviewed-on: https://go-review.googlesource.com/18362
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
f90b48e intended to require the stack barrier lock in all cases of
sigprof that walked the user stack, but got it wrong. In particular,
if sp < gp.stack.lo || gp.stack.hi < sp, tracebackUser would be true,
but we wouldn't acquire the stack lock. If it then turned out that we
were in a cgo call, it would walk the stack without the lock.
In fact, the whole structure of stack locking is sigprof is somewhat
wrong because it assumes the G to lock is gp.m.curg, but all three
gentraceback calls start from potentially different Gs.
To fix this, we lower the gcTryLockStackBarriers calls much closer to
the gentraceback calls. There are now three separate trylock calls,
each clearly associated with a gentraceback and the locked G clearly
matches the G from which the gentraceback starts. This actually brings
the sigprof logic closer to what it originally was before stack
barrier locking.
This depends on "runtime: increase assumed stack size in
externalthreadhandler" because it very slightly increases the stack
used by sigprof; without this other commit, this is enough to blow the
profiler thread's assumed stack size.
Fixes#12528 (hopefully for real this time!).
For the 1.5 branch, though it will require some backporting. On the
1.5 branch, this will *not* require the "runtime: increase assumed
stack size in externalthreadhandler" commit: there's no pcvalue cache,
so the used stack is smaller.
Change-Id: Id2f6446ac276848f6fc158bee550cccd03186b83
Reviewed-on: https://go-review.googlesource.com/18328
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
On Windows, externalthreadhandler currently sets the assumed stack
size for the profiler thread and the ctrlhandler threads to 8KB. The
actual stack size is determined by the SizeOfStackReserve field in the
binary set by the linker, which is currently at least 64KB (and
typically 128KB).
It turns out the profiler thread is running within a few words of the
8KB-(stack guard) bound set by externalthreadhandler. If it overflows
this bound, morestack crashes unceremoniously with an access
violation, which we then fail to handle, causing the whole process to
exit without explanation.
To avoid this problem and give us some breathing room, increase the
assumed stack size in externalthreadhandler to 32KB (there's some
unknown amount of stack already in use, so it's not safe to increase
this all the way to the reserve size).
We also document the relationships between externalthreadhandler and
SizeOfStackReserve to make this more obvious in the future.
Change-Id: I2f9f9c0892076d78e09827022ff0f2bedd9680a9
Reviewed-on: https://go-review.googlesource.com/18304
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>
If a sigprof happens during a cgo call, we traceback from the entry
point of the cgo call. However, if the SP is outside of the G's stack,
we'll then ignore this traceback, even if it was successful, and
overwrite it with just _ExternalCode.
Fix this by accepting any successful traceback, regardless of whether
we got it from a cgo entry point or from regular Go code.
Fixes#13466.
Change-Id: I5da9684361fc5964f44985d74a8cdf02ffefd213
Reviewed-on: https://go-review.googlesource.com/18327
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
net has GODEBUG text already.
net/http still needs it (leaving for Brad).
For #13611.
Change-Id: Icea1027924a23a687cbbe4001985e8c6384629d7
Reviewed-on: https://go-review.googlesource.com/18346
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now there are ARM downloads too.
Change-Id: I236381508c69d56748e672d184b92caa715e81ae
Reviewed-on: https://go-review.googlesource.com/18342
Reviewed-by: Andrew Gerrand <adg@golang.org>
Update bundled http2 to git rev d1ba260648 (https://golang.org/cl/18288).
Fixes the flaky TestTransportAndServerSharedBodyRace_h2.
Also adds some debugging to TestTransportAndServerSharedBodyRace_h2
which I hope won't ever be necessary again, but I know will be.
Fixes#13556
Change-Id: Ibcf2fc23ec0122dcac8891fdc3bd7f8acddd880e
Reviewed-on: https://go-review.googlesource.com/18289
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
After a failure on the build dashboard I tested testcarchive test 2 and
found that it failed an average of 1 in 475 runs on my laptop. With
this change it ran over 50,000 times without failing. I bumped up the
other iteration limits to correspond.
Change-Id: I0155c68161a2c2a09ae25c91e9269f1e8702628d
Reviewed-on: https://go-review.googlesource.com/18309
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Simply checking the exit code of `git rev-parse --git-dir` should
suffice here, but that requires deviating from the infrastructure
provided by `run`, so I've left that for a future change.
Originally by Tamir Duberstein but updated by iant & rsc to add
the filepath.Join logic.
Fixes#11211 (again).
Change-Id: I6d29b5ae39ba456088ae1fb5d41014cb91c86897
Reviewed-on: https://go-review.googlesource.com/18323
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The flag is already named -insecure. Make it more so.
If we're willing to accept HTTP, it's not much worse to accept
HTTPS man-in-the-middle attacks too. This allows servers
with self-signed certificates to work.
Fixes#13197.
Change-Id: Ia5491410bc886da0a26ef3bce4bf7d732f5e19e4
Reviewed-on: https://go-review.googlesource.com/18324
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Read zip files that contain only 64-bit header offset, not 64-bit sizes.
Fixes#13367.
Read zip files that contain completely unexpected Extra fields,
provided we do not need to find 64-bit size or header offset information there.
Fixes#13166.
Write zip file entries with 0xFFFFFFFF uncompressed data bytes
correctly (must use zip64 header, since that's the magic indicator).
Fixes new TestZip64EdgeCase. (Noticed while working on the CL.)
Change-Id: I84a22b3995fafab8052b99de8094a9f35a25de5b
Reviewed-on: https://go-review.googlesource.com/18317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We were setting the signal mask of a new m to the signal mask of the m
that created it. That failed when that m happened to be the one created
by ensureSigM, which sets its signal mask to only include the signals
being caught by os/signal.Notify.
Fixes#13164.
Update #9896.
Change-Id: I705c196fe9d11754e10bab9e9b2e7530ecdfa367
Reviewed-on: https://go-review.googlesource.com/18064
Reviewed-by: Russ Cox <rsc@golang.org>
When calling a Go function on a C thread, if the C thread already has an
alternate signal stack, use that signal stack instead of installing a
new one.
Update #9896.
Change-Id: I62aa3a6a4a1dc4040fca050757299c8e6736987c
Reviewed-on: https://go-review.googlesource.com/18108
Reviewed-by: Russ Cox <rsc@golang.org>
Just saw a few dragonfly failures here.
I'm tempted to preemptively add plan9 here too, but I'll wait until
I see it fail.
Change-Id: Ic99fc088dbfd1aa21f509148aee98ccfe7f640bf
Reviewed-on: https://go-review.googlesource.com/18306
Reviewed-by: Russ Cox <rsc@golang.org>
This time with a test.
Also adjust another test to skip when hg is not present,
and delete no longer needed fixDetachedHead code.
Fixes#9032 (again).
Change-Id: I481717409e1d44b524f83c70a8dc377699d1a2a5
Reviewed-on: https://go-review.googlesource.com/18334
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
But also cache the previous parsed form and don't reread if the
size and modification time are both unchanged from before.
On systems with stable /etc/hosts this should result in more stat calls
but only a single parsing of /etc/hosts.
On systems with variable /etc/hosts files (like some Docker systems)
this should result in quicker adoption of changes.
Fixes#13340.
Change-Id: Iba93b204be73d6d903cd17c58038a4fcfd0952b9
Reviewed-on: https://go-review.googlesource.com/18258
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add a couple more cases where we convert random network I/O errors
into errRequestCanceled if the request was forcefully aborted.
It failed ~1/1000 times without -race, or very easily with -race.
(due to -race randomizing some scheduling)
Fixes#11894
Change-Id: Ib1c123ce1eebdd88642da28a5948ca4f30581907
Reviewed-on: https://go-review.googlesource.com/18287
Reviewed-by: Russ Cox <rsc@golang.org>
This shouldn't need to exist in general, but in practice I want something
like this a few times per year.
Change-Id: I9c220e58be44b7726f75d776f714212c570cf8bb
Reviewed-on: https://go-review.googlesource.com/18286
Reviewed-by: Russ Cox <rsc@golang.org>
The old link died; replace with an archive.org copy.
Fixes#13345.
Change-Id: Ic4a7fdcf258e1ff3b4a02ecb4f237ae7db2686c7
Reviewed-on: https://go-review.googlesource.com/18335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Adds a test that both http1 and http2's Transport send a default
User-Agent, with the same behavior.
Updates bundled http2 to golang.org/x/net git rev 1ade16a545 (for
https://go-review.googlesource.com/18285)
The http1 behavior changes slightly: if req.Header["User-Agent"] is
defined at all, even if it's nil or a zero-length slice, then the
User-Agent header is omitted. This is a slight behavior change for
http1, but is consistent with how http1 & http2 do optional headers
elsewhere (such as "Date", "Content-Type"). The old behavior (set it
explicitly to "", aka []string{""}) still works as before. And now
there are even tests.
Fixes#13685
Change-Id: I5786a6913b560de4a5f1f90e595fe320ff567adf
Reviewed-on: https://go-review.googlesource.com/18284
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The textual export data generated by gc sometimes contains forward
references of packages. In rare cases such forward-referenced packages
were not created when needed because no package name was present.
Create unnamed packages in this case and set the name later when it
becomes known.
Fixes#13566.
Change-Id: I193e0ec712e874030b194ab8ecb3fca140f7997a
Reviewed-on: https://go-review.googlesource.com/18301
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
This was supposed to be in CL 18204 but I submitted from the web
instead of my computer and lost this final edit.
Change-Id: I41598e936bb088d77f5e44752eda74222a4208c7
Reviewed-on: https://go-review.googlesource.com/18310
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This was supposed to be in CL 18205 but I submitted via the web
instead of from my computer, so it got lost.
May deflake some things.
Change-Id: I880fb74b5943b8a17f952a82639c60126701187a
Reviewed-on: https://go-review.googlesource.com/18259
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We don't use these for benchmarking anymore.
Now we have the go1 dir and the benchmarks subrepo.
Some have problematic copyright notices, so move out of main repo.
Preserved in golang.org/x/exp/shootout.
Fixes#12688.
Fixes#13584.
Change-Id: Ic0b71191ca1a286d33d7813aca94bab1617a1c82
Reviewed-on: https://go-review.googlesource.com/18320
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Simply checking the exit code of `git rev-parse --git-dir` should
suffice here, but that requires deviating from the infrastructure
provided by `run`, so I've left that for a future change.
Fixes#11211.
Change-Id: I7cbad86a8a06578f52f66f734f5447b597ddc962
Reviewed-on: https://go-review.googlesource.com/18213
Reviewed-by: Russ Cox <rsc@golang.org>
Since Stop was introduced, it would revert to the system default for the
signal, rather than to the default Go behavior. Change it to revert to
the default Go behavior.
Change-Id: I345467ece0e49e31b2806d6fce2f1937b17905a6
Reviewed-on: https://go-review.googlesource.com/18229
Reviewed-by: Russ Cox <rsc@golang.org>
Mention that:
- connection pooling is enabled by default,
- the Transport is safe for concurrent use, and
- the Client type should be used for high-level stuff.
Change-Id: Idfd8cc852e733c44211e77cf0e22720b1fdca39b
Reviewed-on: https://go-review.googlesource.com/18273
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
