««« CL 135050043 / 57dfd03985a9
cmd/5l, cmd/6l, cmd/8l: fix nacl binary corruption bug
NaCl requires the addition of a 32-byte "halt sled" at the end
of the text segment. This means that segtext.len is actually
32 bytes shorter than reality. The computation of the file offset
of the end of the data segment did not take this 32 bytes into
account, so if len and len+32 rounded up (by 64k) to different
values, the symbol table overwrote the last page of the data
segment.
The last page of the data segment is usually the C .string
symbols, which contain the strings used in error prints
by the runtime. So when this happens, your program
probably crashes, and then when it does, you get binary
garbage instead of all the usual prints.
The chance of hitting this with a randomly sized text segment
is 32 in 65536, or 1 in 2048.
If you add or remove ANY code while trying to debug this
problem, you're overwhelmingly likely to bump the text
segment one way or the other and make the bug disappear.
Correct all the computations to use segdata.fileoff+segdata.filelen
instead of trying to rederive segdata.fileoff.
This fixes the failure during the nacl/amd64p32 build.
TBR=iant
CC=golang-codereviews
https://golang.org/cl/135050043
»»»
LGTM=bradfitz
R=golang-codereviews
CC=adg, bradfitz, golang-codereviews, iant
https://golang.org/cl/151150044
The GOROOT baked into the go command being run is correct.
The GOROOT in the environment may not be. Remove it.
Fixes nacltest.bash if you have GOROOT set elsewhere.
This is already fixed in the default branch.
LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/147380044
Only Unix was resetting the traceback_cache variable
after initializing the environment. Reset it on all systems
by resetting in parsedebugvars.
Fixes#8813.
LGTM=adg, alex.brainman
R=golang-codereviews, adg, alex.brainman
CC=golang-codereviews, iant, r
https://golang.org/cl/152760043
The linker error at
http://build.golang.org/log/42c57ff6b57ab36f6622417108bb5697e4d36fa7
is a false positive: cgocallback_gofunc is invoked on the g0 stack,
as explained in its comments, and then it switches to the m->curg
stack to invoke cgocallbackg. Checking the stacksplit sequence
on the g0 stack doesn't make sense, nor does carrying a check
that starts on the g0 stack over to the curg stack.
Change the code to use an indirect call so that the linker
stacksplit check does not follow through it.
LGTM=bradfitz, adg
R=golang-codereviews, bradfitz, adg
CC=golang-codereviews, iant, r
https://golang.org/cl/146510043
««« CL 130920043 / 7dba9475ee72
time: removed from tests now obsolete assumption about Australian tz abbreviations
Australian timezones abbreviation for standard and daylight saving time were recently
changed from EST for both to AEST and AEDT in the icann tz database (see changelog
on www.iana.org/time-zones).
A test in the time package was written to check that the ParseInLocation function
understand that Feb EST and Aug EST are different time zones, even though they are
both called EST. This is no longer the case, and the Date function now returns
AEST or AEDT for australian tz on every Linux system with an up to date tz database
(and this makes the test fail).
Since I wasn't able to find another country that 1) uses daylight saving and 2) has
the same abbreviation for both on tzdata, I changed the test to make sure that
ParseInLocation does not get confused when it parses, in different locations, two
dates with the same abbreviation (this was suggested in the mailing list).
Fixes#8547.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/130920043
»»»
LGTM=dsymonds
R=rsc, dsymonds
CC=golang-codereviews
https://golang.org/cl/153720043
A security bug affects programs that use crypto/tls to implement a TLS server
from Go 1.1 onwards. If the server enables TLS client authentication using
certificates (this is rare) and explicitly sets SessionTicketsDisabled to true
in the tls.Config, then a malicious client can falsely assert ownership of any
client certificate it wishes.
This issue was discovered internally and there is no evidence of exploitation.
Change authored by Adam Langley <agl@golang.org>
https://golang.org/cl/148080043/
This is a manual backport of CL 131910043
to the Go 1.3 release branch.
We believe this CL can cause arbitrary corruption
in programs that call into C from Go and then
call back into Go from C.
This change will be released in Go 1.3.2.
LGTM=iant
R=iant, hector
CC=adg, dvyukov, golang-codereviews, r
https://golang.org/cl/142690043
This fails on my OS X machine,
just like it did in default branch.
In the default branch we removed the test.
It's just buggy.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/144610043
««« CL 129180043 / cf5017c4a780
doc: make it point to correct go1.3.1 change history
LGTM=minux, adg
R=golang-codereviews, minux, adg
CC=golang-codereviews
https://golang.org/cl/129180043
»»»
TBR=r
CC=golang-codereviews
https://golang.org/cl/122670043
It broke the build across all platforms.
The original change wasn't even reviewed.
Probably should never have been ported to this branch.
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/128130043
««« CL 120820043 / 06a4b59c1393
net: prevent spurious on-connect events via epoll on linux
On Linux, adding a socket descriptor to epoll instance before getting
the EINPROGRESS return value from connect system call could be a root
cause of spurious on-connect events.
See golang.org/issue/8276, golang.org/issue/8426 for further information.
All credit to Jason Eggleston <jason@eggnet.com>
Fixes#8276.
Fixes#8426.
LGTM=dvyukov
R=dvyukov, golang-codereviews, adg, dave, iant, alex.brainman
CC=golang-codereviews
https://golang.org/cl/120820043
»»»
TBR=r, rsc
CC=golang-codereviews
https://golang.org/cl/128110045
««« CL 125720043 / b92e5df7d3ba
cmd/gc: make liveness ~10x faster
1) The arrayindexof lookup function is O(n). Replace with O(1) lookups.
2) The checkptxt function is O(n²) and is purely for debugging.
Only run when the debugging flags are turned on.
3) Iterating over sparse bitmaps can be done faster word by word.
Introduce and use bvnext for that.
Run times before and after, on my 2.5 GHz Core i5 MacBook Pro.
x.go 9.48 0.84 issue 8259
x100.go 0.01 0.01 issue 8354
x1000.go 0.10 0.10
x2000.go 0.62 0.19
x3000.go 1.33 0.34
x4000.go 2.29 0.49
x5000.go 3.89 0.67
x6000.go 5.00 0.90
x7000.go 6.70 1.13
x8000.go 9.44 1.38
x9000.go 11.23 1.87
x10000.go 13.78 2.09
Fixes#8259.
Fixes#8354.
LGTM=iant, r
R=golang-codereviews, iant, r
CC=golang-codereviews
https://golang.org/cl/125720043
»»»
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/121600043
««« CL 118670043 / 671fa8a9eb80
runtime: turn off 'unexpected return pc' print on arm traceback
It can happen legitimately if a profiling signal arrives at just the wrong moment.
It's harmless.
Fixes#8153.
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews, iant, r
https://golang.org/cl/118670043
»»»
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/127950044
««« CL 102670044 / c5f72a685e25
crypto/rsa: fix out-of-bound access with short session keys.
Thanks to Cedric Staub for noting that a short session key would lead
to an out-of-bounds access when conditionally copying the too short
buffer over the random session key.
LGTM=davidben, bradfitz
R=davidben, bradfitz
CC=golang-codereviews
https://golang.org/cl/102670044
»»»
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/128930044
««« CL 122850043 / 0015a2541545
cmd/cgo: fix recursive type mapping
Instead of immediately completing pointer type mappings, add them to
a queue to allow them to be completed later. This fixes issues caused
by Type() returning arbitrary in-progress type mappings.
Fixes#8368.
Fixes#8441.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/122850043
»»»
TBR=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/128940043
««« CL 102710043 / 5640e19d768d
runtime: fix nacl amd64p32 flakiness
newproc takes two extra pointers, not two extra registers.
On amd64p32 (nacl) they are different.
We diagnosed this before the 1.3 cut but the tree was frozen.
I believe this is causing the random problems on the builder.
Fixes#8199.
TBR=r
CC=golang-codereviews
https://golang.org/cl/102710043
»»»
TBR=rsc
CC=golang-codereviews
https://golang.org/cl/124120044
««« CL 112650043 / bdac8d858e74
doc: drop scheme from links that are known to support HTTPS
golang.org now serves HTTPS with a valid cert, so it's reasonable
that users should click through to the HTTPS versions of *.golang.org
and other known sites.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/112650043
»»»
TBR=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/111700043
««« CL 103480043 / 777dd5a434db
fmt: fix signs when zero padding.
Bug was introduced recently. Add more tests, fix the bugs.
Suppress + sign when not required in zero padding.
Do not zero pad infinities.
All old tests still pass.
This time for sure!
Fixes#8217.
LGTM=rsc
R=golang-codereviews, dan.kortschak, rsc
CC=golang-codereviews
https://golang.org/cl/103480043
»»»
LGTM=r, rsc
R=r, rsc
CC=golang-codereviews
https://golang.org/cl/110040043
««« CL 88560044 / d011c0dcae9c
doc: add release note for 'godoc -analysis'
Contains a link to /lib/godoc/analysis/help.html
which is not yet live.
LGTM=r
R=r, adg
CC=golang-codereviews
https://golang.org/cl/88560044
»»»
TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/104150043
««« CL 105120044 / 824ea5943ba8
runtime: revise CL 105140044 (defer nil) to work on Windows
It appears that something about Go on Windows
cannot handle the fault cause by a jump to address 0.
The way Go represents and calls functions, this
never happened at all, until CL 105140044.
This CL changes the code added in CL 105140044
to make jump to 0 impossible once again.
Fixes#8047. (again, on Windows)
TBR=bradfitz
R=golang-codereviews, dave
CC=adg, golang-codereviews, iant, r
https://golang.org/cl/105120044
»»»
LGTM=bradfitz
R=golang-codereviews, bradfitz, alex.brainman
CC=adg, golang-codereviews
https://golang.org/cl/108890045
The Windows build is still bad. The previous CL is not go1.3rc2.
TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/107050043
««« CL 107970043 / b336da131a84
runtime: do not trace past jmpdefer during pprof traceback on arm
jmpdefer modifies PC, SP, and LR, and not atomically,
so walking past jmpdefer will often end up in a state
where the three are not a consistent execution snapshot.
This was causing warning messages a few frames later
when the traceback realized it was confused, but given
the right memory it could easily crash instead.
Update #8153
LGTM=minux, iant
R=golang-codereviews, minux, iant
CC=golang-codereviews, r
https://golang.org/cl/107970043
»»»
LGTM=r
R=golang-codereviews, r
CC=adg, golang-codereviews, iant
https://golang.org/cl/101260043
««« CL 107950043 / 593f58ee96da
doc: link to release history from /doc/
Fixes#8168.
TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/107950043
»»»
LGTM=r
R=golang-codereviews, r
CC=adg, golang-codereviews, iant
https://golang.org/cl/105910043
««« CL 108860043 / f153208c0a0e
cmd/gc: fix escape analysis for &x inside switch x := v.(type)
The analysis for &x was using the loop depth on x set
during x's declaration. A type switch creates a list of
implicit declarations that were not getting initialized
with loop depths.
Fixes#8176.
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108860043
»»»
««« CL 108870044 / 331dbd4a6334
cmd/gc: fix &result escaping into result
There is a hierarchy of location defined by loop depth:
-1 = the heap
0 = function results
1 = local variables (and parameters)
2 = local variable declared inside a loop
3 = local variable declared inside a loop inside a loop
etc
In general if an address from loopdepth n is assigned to
something in loop depth m < n, that indicates an extended
lifetime of some form that requires a heap allocation.
Function results can be local variables too, though, and so
they don't actually fit into the hierarchy very well.
Treat the address of a function result as level 1 so that
if it is written back into a result, the address is treated
as escaping.
Fixes issue 8185 .
LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108870044
»»»
LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/107930044
