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/2819Reviewed-by: Rick Hudson <rlh@golang.org>
Showing
Please register or sign in to comment