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 #8675. LGTM=iant R=golang-codereviews, iant CC=dave, golang-codereviews, khr, minux, r https://golang.org/cl/135570043
Showing
Please register or sign in to comment