Commit 08594ac7 authored by Austin Clements's avatar Austin Clements Committed by Russ Cox

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: default avatarRuss Cox <rsc@golang.org>
parent eb3b1830
...@@ -529,7 +529,12 @@ func traceEvent(ev byte, skip int, args ...uint64) { ...@@ -529,7 +529,12 @@ func traceEvent(ev byte, skip int, args ...uint64) {
nstk = callers(skip, buf.stk[:]) nstk = callers(skip, buf.stk[:])
} else if gp != nil { } else if gp != nil {
gp = mp.curg 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 { if nstk > 0 {
nstk-- // skip runtime.goexit nstk-- // skip runtime.goexit
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment