Age | Commit message (Collapse) | Author |
|
This fixes a race between 1) sweeping and freeing an unmarked large
span and 2) reusing that span and allocating from it. This race arises
because mSpan_Sweep returns spans for large objects to the heap
*before* heapBitsSweepSpan clears the mark bit on the object in the
span.
Specifically, the following sequence of events can lead to an
incorrectly zeroed bitmap byte, which causes the garbage collector to
not trace any pointers in that object (the pointer bits for the first
four words are cleared, and the scan bits are also cleared, so it
looks like a no-scan object).
1) P0 calls mSpan_Sweep on a large span S0 with an unmarked object on it.
2) mSpan_Sweep calls heapBitsSweepSpan, which invokes the callback for
the one (unmarked) object on the span.
3) The callback calls mHeap_Free, which makes span S0 available for
allocation, but this is too early.
4) P1 grabs this S0 from the heap to use for allocation.
5) P1 allocates an object on this span and writes that object's type
bits to the bitmap.
6) P0 returns from the callback to heapBitsSweepSpan.
heapBitsSweepSpan clears the byte containing the mark, even though
this span is now owned by P1 and this byte contains important
bitmap information.
This fixes this problem by simply delaying the mHeap_Free until after
the heapBitsSweepSpan. I think the overall logic of mSpan_Sweep could
be simplified now, but this seems like the minimal change.
Fixes #11617.
Change-Id: I6b1382c7e7cc35f81984467c0772fe9848b7522a
Reviewed-on: https://go-review.googlesource.com/12320
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Adjusts for the move from golang.org/x/tools/go/types and .../go/exact
to go/types and go/constant in the main repository.
Change-Id: I0da7248c540939e3e9b09c915b0a296937f1be73
Reviewed-on: https://go-review.googlesource.com/12284
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Change-Id: Ia7cc1d52211b32a2eb2b3888d621b28d6932aca9
Reviewed-on: https://go-review.googlesource.com/12290
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: I912cafc66463f81cde839afc8f06b7eadcbf6f57
Reviewed-on: https://go-review.googlesource.com/11992
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Update #10639
Change-Id: I2d7817ac0aefb5dd2569d7e83afbc51851e24b42
Reviewed-on: https://go-review.googlesource.com/12321
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
At least the most important parts, I think.
Fixes #10552
Change-Id: I1a03c5405bdbef337e0245d226e9247d3d067393
Reviewed-on: https://go-review.googlesource.com/12246
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The iOS simulator compiles with GOOS=darwin GOARCH=386, and x509
sets the inappropriate flag -mmacosx-version-min=10.6. Condition
its compilation on the absence of an "ios" build tag.
Fixes #11736.
Change-Id: I4aa230643347320c3cb9d03b972734b2e0db930e
Reviewed-on: https://go-review.googlesource.com/12301
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: I9db1997b8dc7e06e9d124753ead6221470a1edf9
Reviewed-on: https://go-review.googlesource.com/12254
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Also add a link to a couple of the talks from GopherCon 2015.
Change-Id: I11e1c550e999553163d3fb5e900f167c849ce33f
Reviewed-on: https://go-review.googlesource.com/12287
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
No code changes.
Change-Id: I3b78b1048318a4b80747fde8cab919282fc444a8
Reviewed-on: https://go-review.googlesource.com/12285
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
For #11656.
Change-Id: I8365d33a15419bd0e54f71182ad0994e41650264
Reviewed-on: https://go-review.googlesource.com/12248
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Broke arm64. Update #9880.
This reverts commit 38d9b2a3a942892193195a6912ab23cdaff23e20.
Change-Id: I35fa21005af2183828a9d8b195ebcfbe45ec5138
Reviewed-on: https://go-review.googlesource.com/12247
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Change-Id: I6f79d201aa4e8c0e3be8d965f14ed36518536036
Reviewed-on: https://go-review.googlesource.com/12281
Reviewed-by: Rob Pike <r@golang.org>
|
|
Updates #10639
Change-Id: Ifece75b8d1d822869df8abf654725a00bef4fc25
Reviewed-on: https://go-review.googlesource.com/12280
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This seems to have broken arm64 in a mysterious way. Will try again later.
This reverts commit 0a3c991fd330276f6876c401541dcbacbb860985.
Change-Id: Ic1b53413c4168977a27381d9cc6fb8d9d7cbb780
Reviewed-on: https://go-review.googlesource.com/12245
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
If we receive an HTTP request with "Expect: 100-continue" and the
Handler never read to EOF, the conn is in an unknown state.
Don't reuse that connection.
Fixes #11549
Change-Id: I5be93e7a54e899d615b05f72bdcf12b25304bc60
Reviewed-on: https://go-review.googlesource.com/12262
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Updates #10639
Change-Id: I0958e150f6eab122095bfc148746a38028b72dbc
Reviewed-on: https://go-review.googlesource.com/12263
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Now that we care about the protocol of Git remotes (for the -insecure
flag), we need to recognize and parse the SCP-like remote format.
Fixes golang/go#11457
Change-Id: Ia26132274fafb1cbfefe2475f7ac5f17ccd6da40
Reviewed-on: https://go-review.googlesource.com/12226
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Running a safe-point function on syscall entry uses systemstack() and
hence clobbers g.sched.pc and g.sched.sp. Fix this by re-saving them
after the systemstack, just like in the other uses of systemstack in
reentersyscall.
Change-Id: I47868a53eba24d81919fda56ef6bbcf72f1f922e
Reviewed-on: https://go-review.googlesource.com/12125
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Currently, we run a P's safe-point function immediately after entering
_Psyscall state. This is unsafe, since as soon as we put the P in
_Psyscall, we no longer control the P and another M may claim it.
We'll still run the safe-point function only once (because doing so
races on an atomic), but the P may no longer be at a safe-point when
we do so.
In particular, this means that the use of forEachP to dispose all P's
gcw caches is unsafe. A P may enter a syscall, run the safe-point
function, and dispose the P's gcw cache concurrently with another M
claiming the P and attempting to use its gcw cache. If this happens,
we may empty the gcw's workbuf after putting it on
work.{full,partial}, or add pointers to it after putting it in
work.empty. This will cause an assertion failure when we later pop the
workbuf from the list and its object count is inconsistent with the
list we got it from.
Fix this by running the safe-point function just before putting the P
in _Psyscall.
Related to #11640. This probably fixes this issue, but while I'm able
to show that we can enter a bad safe-point state as a result of this,
I can't reproduce that specific failure.
Change-Id: I6989c8ca7ef2a4a941ae1931e9a0748cbbb59434
Reviewed-on: https://go-review.googlesource.com/12124
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Change-Id: I945d46d3bb63f1992bce0d0b1e89e75cac9bbd54
Reviewed-on: https://go-review.googlesource.com/12271
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
There was already special code to recognize "?" in hidden_structdcl,
which is used for inlined types and variables. This recognizes "?" in
structdcl as well, a case that arises when a struct type appears
within an inlined function body.
Fixes #10219.
Change-Id: Ic5257ae54f817e0d4a189c2294dcd633c9f2101a
Reviewed-on: https://go-review.googlesource.com/12241
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Fixes #8837.
Change-Id: Iaaecbb0b324004cb74b16b764126b01315e6a16e
Reviewed-on: https://go-review.googlesource.com/12209
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
The parser treats (R1+R2) on ppc64 the same as (R1,R2) on arm,
but it is not strictly a "register pair". Improve the text.
No semantic change.
Change-Id: Ib8b14881c6467add0d53150a901c01e962afb28b
Reviewed-on: https://go-review.googlesource.com/12212
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
For #9880. Let's see what breaks.
Change-Id: Ic8b99a604e60177a448af5f7173595feed607875
Reviewed-on: https://go-review.googlesource.com/10818
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
|
|
Fixes #8427.
Change-Id: I826a3bc4519845ad30d6dbaf058fe7ed7bee8db0
Reviewed-on: https://go-review.googlesource.com/12233
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
- Make Log2 exact for powers of two.
- Fix error tolerance function to make tolerance
a function of the correct (expected) value.
Fixes #9066.
Change-Id: I0320a93ce4130deed1c7b7685627d51acb7bc56d
Reviewed-on: https://go-review.googlesource.com/12230
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
TextUnmarshaler
Fixes #9650.
Change-Id: I45b879124691e485b86c1e99a3227032283850d2
Reviewed-on: https://go-review.googlesource.com/12208
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Fixes #9140.
Change-Id: I3b85053262cac3c30358f8e03a5aca65dbc67623
Reviewed-on: https://go-review.googlesource.com/12231
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Originally 'go test -h' printed the output of 'go help test'.
Then issue #6576 was filed, because that output didn't list (for example) -bench.
CL 14502065 changed 'go test -h' to print the output of 'go help testflag'.
Then issue #9209 was filed, because that output didn't list (for example) -c.
To print all the relevant flags, parts of both 'go help test' and 'go help testflag'
are needed. Refactor the help messages to make those parts available
and print them.
Fixes #9209.
Change-Id: Ie8205b8fb37d00c10d25b3fc98f14286ec46c4e3
Reviewed-on: https://go-review.googlesource.com/12173
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #10731.
Change-Id: I105629b03fd3323c0a2ca5b6b0fd35ee92b7fd2e
Reviewed-on: https://go-review.googlesource.com/12146
Reviewed-by: Rob Pike <r@golang.org>
|
|
Before, calling the RGBA method of YCbCr color would return red values
in the range [0x0080, 0xff80]. After, the range is [0x0000, 0xffff] and
is consistent with what Gray colors' RGBA method returns. In particular,
pure black, pure white and every Gray color in between are now exactly
representable as a YCbCr color.
This fixes a regression from Go 1.4 (where YCbCr{0x00, 0x80, 0x80} was
no longer equivalent to pure black), introduced by golang.org/cl/8073 in
the Go 1.5 development cycle. In Go 1.4, the +0x80 rounding was not
noticable when Cb == 0x80 && Cr == 0x80, because the YCbCr to RGBA
conversion truncated to 8 bits before multiplying by 0x101, so the
output range was [0x0000, 0xffff].
The TestYCbCrRoundtrip fuzzy-match tolerance grows from 1 to 2 because
the YCbCr to RGB conversion now maps to an ever-so-slightly larger
range, along with the usual imprecision of accumulating rounding errors.
Also s/int/int32/ in ycbcr.go. The conversion shouldn't overflow either
way, as int is always at least 32 bits, but it does make it clearer that
the computation doesn't depend on sizeof(int).
Fixes #11691
Change-Id: I538ca0adf7e040fa96c5bc8b3aef4454535126b9
Reviewed-on: https://go-review.googlesource.com/12220
Reviewed-by: Rob Pike <r@golang.org>
|
|
Change-Id: I0f167d9769d9b6b9888c13fcb48e538fc87aa1b7
Reviewed-on: https://go-review.googlesource.com/12240
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Fixes #10963.
Change-Id: I8d769b4d25b306f2df41f882ec01d97bbd63171d
Reviewed-on: https://go-review.googlesource.com/12221
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Fixes #10338.
Change-Id: Ib86cb9a6c694b1e442a9957153c7ca38a7d11c3e
Reviewed-on: https://go-review.googlesource.com/12232
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #9427.
Change-Id: If8094d4d4f6737c03d83e08e177c2a7f0ff9d89f
Reviewed-on: https://go-review.googlesource.com/12234
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Fixes #3652. (Well, already fixed, but tests that it stays fixed.)
Change-Id: I4e17f595ee2ad513de86ac3861e8e66b1230b3be
Reviewed-on: https://go-review.googlesource.com/12195
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Failures noted by dashboard.
Change-Id: I22f90120c6687b64b9efff9df7a7fa8f26d24bac
Reviewed-on: https://go-review.googlesource.com/12207
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Fixes #9357.
Change-Id: I11f0652758c4ea80debec29c3b99a72baca6d745
Reviewed-on: https://go-review.googlesource.com/12193
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #9224.
Change-Id: Ie0f4f14407099e4fa7ebe361a95b6492012928a2
Reviewed-on: https://go-review.googlesource.com/12192
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This fix only works on Git 2.3.0 and later.
There appears to be no portable way to fix the earlier versions.
We already run git with stdin closed, but on Unix git calls getpass,
which opens /dev/tty itself. We could do package syscall-specific
things to get /dev/tty invalidated during the exec, but I'd really
rather not. And on Windows, Git opens "CONIN$" and "CONOUT$"
itself, and I have no idea how to invalidate those.
Fix the problem for newish Git versions and wait for people to update.
Best we can do.
Fixes #9341.
Change-Id: I576579b106764029853e0f74d411e19108deecf5
Reviewed-on: https://go-review.googlesource.com/12175
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #8952.
Change-Id: I678f9706eccb5a344eeb0244f45b7b7669830bdc
Reviewed-on: https://go-review.googlesource.com/12204
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Fixes #9146.
Change-Id: If5cb5ae92a201825b9ff32b3d0edfa032b9a0965
Reviewed-on: https://go-review.googlesource.com/12203
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Fixes #9180.
Change-Id: Id5adaea0ca9005946fb89c88a10c6f59d8c0943c
Reviewed-on: https://go-review.googlesource.com/12202
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Fixes #10259.
Change-Id: Ica6b8301cc8291785a3c496fb513050813b2d8df
Reviewed-on: https://go-review.googlesource.com/12201
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Fixes #11305.
Change-Id: Icaa3a009aa4ab214c9aaf74f52c3e622fa266a9d
Reviewed-on: https://go-review.googlesource.com/12194
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #11090.
Change-Id: I1518df7a48346b175ec80079a07225901fdd51fb
Reviewed-on: https://go-review.googlesource.com/12177
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #9558.
Change-Id: I68506af58088155d38d492b49b19c5fc2048b087
Reviewed-on: https://go-review.googlesource.com/12176
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fix now uses same test as 'go build'.
Fixes #10500.
Change-Id: I2fcf2d95430643370aa29165d89a188988dee446
Reviewed-on: https://go-review.googlesource.com/12174
Reviewed-by: Rob Pike <r@golang.org>
|
|
Also use more consistent language for the new build options.
Change-Id: I88cbe200c13f452713be73d2e00337ddb793b8c6
Reviewed-on: https://go-review.googlesource.com/12172
Reviewed-by: Rob Pike <r@golang.org>
|