mirror of https://github.com/golang/go.git
runtime: fix accounting race in printlock
It could happen that mp.printlock++ happens, then on entry to lock, the goroutine is preempted and then rescheduled onto another m for the actual call to lock. Now the lock and the printlock++ have happened on different m's. This can lead to printlock not being unlocked, which either gives a printing deadlock or a crash when the goroutine reschedules, because m.locks > 0. Change-Id: Ib0c08740e1b53de3a93f7ebf9b05f3dceff48b9f Reviewed-on: https://go-review.googlesource.com/2819 Reviewed-by: Rick Hudson <rlh@golang.org>
This commit is contained in:
parent
3be0a0ef6f
commit
bfeda9188a
|
|
@ -53,10 +53,12 @@ var debuglock mutex
|
|||
|
||||
func printlock() {
|
||||
mp := getg().m
|
||||
mp.locks++ // do not reschedule between printlock++ and lock(&debuglock).
|
||||
mp.printlock++
|
||||
if mp.printlock == 1 {
|
||||
lock(&debuglock)
|
||||
}
|
||||
mp.locks-- // now we know debuglock is held and holding up mp.locks for us.
|
||||
}
|
||||
|
||||
func printunlock() {
|
||||
|
|
|
|||
Loading…
Reference in New Issue