From: Austin Clements <austin@google.com>
Date: Thu, 21 Jun 2018 20:56:13 +0000 (-0400)
Subject: runtime: avoid recursive panic on bad lock count
X-Git-Tag: go1.11beta1~32
X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=4991bc6257a9e9d922f7b6e29e393d764c4e4295;p=gostls13.git

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 9ba7e1063f..ce367cfa70 100644
--- 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