Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 08594ac

Browse files
aclementsrsc
authored andcommittedJan 27, 2016
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 <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Russ Cox <[email protected]>
1 parent eb3b183 commit 08594ac

File tree

1 file changed

+6
-1
lines changed

1 file changed

+6
-1
lines changed
 

‎src/runtime/trace.go

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -529,7 +529,12 @@ func traceEvent(ev byte, skip int, args ...uint64) {
529529
nstk = callers(skip, buf.stk[:])
530530
} else if gp != nil {
531531
gp = mp.curg
532-
nstk = gcallers(gp, skip, buf.stk[:])
532+
// This may happen when tracing a system call,
533+
// so we must lock the stack.
534+
if gcTryLockStackBarriers(gp) {
535+
nstk = gcallers(gp, skip, buf.stk[:])
536+
gcUnlockStackBarriers(gp)
537+
}
533538
}
534539
if nstk > 0 {
535540
nstk-- // skip runtime.goexit

0 commit comments

Comments
 (0)
Please sign in to comment.