From 08594ac7c7e123d4aa46f60690da0a7e4034f4e9 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Tue, 26 Jan 2016 17:26:55 -0500 Subject: [PATCH] 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 TryBot-Result: Gobot Gobot Reviewed-by: Russ Cox --- src/runtime/trace.go | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/runtime/trace.go b/src/runtime/trace.go index 58956383a3b..805c34f4834 100644 --- 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