commit 2a3daa8bdd5bd06808c51cb4f2921655f70d7617 [browse]
Author: Andrew Gerrand
Date: 2014-06-13 13:24:50 +10:00

go1.3rc2

LGTM=minux, rsc
R=golang-codereviews, minux, rsc
CC=golang-codereviews
https://golang.org/cl/105170044

commit 64de40a55106b85e648d59b6a0fd4e27be4a10d2 [browse]
Author: Russ Cox
Date: 2014-06-12 21:52:52 -04:00

[release-branch.go1.3] runtime: revise CL 105140044 (defer nil) to work on Windows

««« 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

commit 69616e4e5bb4ef4dfbc065bef3df195ce8619e56 [browse]
Author: Andrew Gerrand
Date: 2014-06-13 10:12:29 +10:00

revert go1.3rc2

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

commit 4dc991cd3f934c10bc4a25fa6252ce7d374309a2 [browse]
Author: Andrew Gerrand
Date: 2014-06-13 09:41:58 +10:00

go1.3rc2

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/103420043

commit 1305c4ce9d0af20b84bacf9029f839ad8e56b392 [browse]
Author: Russ Cox
Date: 2014-06-12 16:55:36 -04:00

[release-branch.go1.3] runtime: do not trace past jmpdefer during pprof traceback on arm

««« 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