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>

diff --git a/src/runtime/panic.go b/src/runtime/panic.go
index 9ba7e1063f3c619fd24917b76f90ec8e082dfac8..ce367cfa70fc02760b68c03123cb7b324f50ff59 100644 (file)
--- a/src/runtime/panic.go
+++ b/src/runtime/panic.go
@@ -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