mirror of
https://github.com/golang/go.git
synced 2025-12-08 06:10:04 +00:00
runtime: avoid recursive panic on bad lock count
Currently, if lock or unlock calls throw because the g.m.lock count is corrupted, we're unlikely to get a stack trace because startpanic_m will itself attempt to acquire a lock, causing a recursive failure. Avoid this by forcing the g.m.locks count to a sane value if it's currently bad. This might be enough to get a stack trace from #25128. Change-Id: I52d7bd4717ffae94a821f4249585f3eb6cd5aa41 Reviewed-on: https://go-review.googlesource.com/120416 Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit is contained in:
parent
011ea87921
commit
4991bc6257
1 changed files with 6 additions and 0 deletions
|
|
@ -716,6 +716,12 @@ func startpanic_m() bool {
|
|||
// happen (even if we're not in one of these situations).
|
||||
_g_.m.mallocing++
|
||||
|
||||
// If we're dying because of a bad lock count, set it to a
|
||||
// good lock count so we don't recursively panic below.
|
||||
if _g_.m.locks < 0 {
|
||||
_g_.m.locks = 1
|
||||
}
|
||||
|
||||
switch _g_.m.dying {
|
||||
case 0:
|
||||
_g_.m.dying = 1
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue