From a0dbbeae6785ed7fd15feb4feb4975eded83c191 Mon Sep 17 00:00:00 2001 From: Dmitriy Vyukov Date: Thu, 21 Aug 2014 11:46:53 +0400 Subject: runtime: fix deadlock when gctrace Calling ReadMemStats which does stoptheworld on m0 holding locks was not a good idea. Stoptheworld holding locks is a recipe for deadlocks (added check for this). Stoptheworld on g0 may or may not work (added check for this as well). As far as I understand scavenger will print incorrect numbers now, as stack usage is not subtracted from heap. But it's better than deadlocking. LGTM=khr R=golang-codereviews, rsc, khr CC=golang-codereviews, rlh https://golang.org/cl/124670043 --- src/pkg/runtime/proc.c | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'src/pkg/runtime/proc.c') diff --git a/src/pkg/runtime/proc.c b/src/pkg/runtime/proc.c index 2510a421a8..8584cb6f6a 100644 --- a/src/pkg/runtime/proc.c +++ b/src/pkg/runtime/proc.c @@ -498,6 +498,14 @@ runtime·stoptheworld(void) P *p; bool wait; + // If we hold a lock, then we won't be able to stop another M + // that is blocked trying to acquire the lock. + if(g->m->locks > 0) + runtime·throw("stoptheworld: holding locks"); + // There is no evidence that stoptheworld on g0 does not work, + // we just don't do it today. + if(g == g->m->g0) + runtime·throw("stoptheworld: on g0"); runtime·lock(&runtime·sched.lock); runtime·sched.stopwait = runtime·gomaxprocs; runtime·atomicstore((uint32*)&runtime·sched.gcwaiting, 1); -- cgit v1.3