qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-09-25 09:20:18 -06:00
Code Releases Activity

runtime: acquire stack lock in traceEvent

Browse Source 
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>
This commit is contained in:
Austin Clements 2016-01-26 17:26:55 -05:00 committed by Russ Cox
parent eb3b1830b0
commit 08594ac7c7
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/runtime/trace.go
View File

@ -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