runtime: acquire stack lock in traceEvent

traceEvent records system call events after a G has already entered
_Gsyscall, which means the garbage collector could be installing stack
barriers in the G's stack during the traceEvent. If traceEvent
attempts to capture the user stack during this, it may observe a
inconsistent stack barriers and panic. Fix this by acquiring the stack
lock around the stack walk in traceEvent.

Fixes #14101.

Change-Id: I15f0ab0c70c04c6e182221f65a6f761c5a896459
Reviewed-on: https://go-review.googlesource.com/18973
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

diff --git a/src/runtime/trace.go b/src/runtime/trace.go
index 58956383a3b18a25df5a191daac5eebd0d585cb7..805c34f483446ef07806524c619ec4e8cf6df68a 100644 (file)
--- a/src/runtime/trace.go
+++ b/src/runtime/trace.go
@@ -529,7 +529,12 @@ func traceEvent(ev byte, skip int, args ...uint64) {
                        nstk = callers(skip, buf.stk[:])
                } else if gp != nil {
                        gp = mp.curg
-                       nstk = gcallers(gp, skip, buf.stk[:])
+                       // This may happen when tracing a system call,
+                       // so we must lock the stack.
+                       if gcTryLockStackBarriers(gp) {
+                               nstk = gcallers(gp, skip, buf.stk[:])
+                               gcUnlockStackBarriers(gp)
+                       }
                }
                if nstk > 0 {
                        nstk-- // skip runtime.goexit