diff options
author | Russ Cox <rsc@golang.org> | 2014-09-07 19:47:40 -0400 |
---|---|---|
committer | Russ Cox <rsc@golang.org> | 2014-09-07 19:47:40 -0400 |
commit | 8515efad2351fed4cc46b761b868cd21df69606e (patch) | |
tree | c2a19b1b069d75b49c5d1cafa1b0ff2900a4ec80 /src/pkg/internal | |
parent | ab55bc9492b051b0b7ac861a9d7e0709520dd854 (diff) | |
download | go-8515efad2351fed4cc46b761b868cd21df69606e.tar.gz |
runtime: save g to TLS more aggressively
This is one of those "how did this ever work?" bugs.
The current build failures are happening because
a fault comes up while executing on m->curg on a
system-created thread using an m obtained from needm,
but TLS is set to m->g0, not m->curg. On fault,
sigtramp starts executing, assumes r10 (g) might be
incorrect, reloads it from TLS, and gets m->g0, not
m->curg. Then sighandler dutifully pushes a call to
sigpanic onto the stack and returns to it.
We're now executing on the m->curg stack but with
g=m->g0. Sigpanic does a stack split check, sees that
the SP is not in range (50% chance depending on relative
ordering of m->g0's and m->curg's stacks), and then
calls morestack. Morestack sees that g=m->g0 and
crashes the program.
The fix is to replace every change of g in asm_arm.s
with a call to a function that both updates g and
saves the updated g to TLS.
Why did it start happening? That's unclear.
Unfortunately there were other bugs in the initial
checkin that mask exactly which of a sequence of
CLs started the behavior where sigpanic would end
up tripping the stack split.
Fixes arm build.
Fixes issue 8675.
LGTM=iant
R=golang-codereviews, iant
CC=dave, golang-codereviews, khr, minux, r
https://codereview.appspot.com/135570043
Diffstat (limited to 'src/pkg/internal')
0 files changed, 0 insertions, 0 deletions