From: Kevin Burke Date: Mon, 24 Feb 2020 04:45:51 +0000 (-0800) Subject: [release-branch.go1.14] doc/articles/race_detector: mention memory leak potential X-Git-Tag: go1.14.1~16 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=99f8de733936785d0e5c0d1271539d3f2f26d009;p=gostls13.git [release-branch.go1.14] doc/articles/race_detector: mention memory leak potential As far as I can tell, there is no public documentation on this topic, which cost me several days of debugging. I am possibly unusual in that I run binaries in production with the race detector turned on, but I think that others who do the same may want to be aware of the risk. Updates #26813. Updates #37233. Change-Id: I1f8111bd01d0000596e6057b7cb5ed017d5dc655 Reviewed-on: https://go-review.googlesource.com/c/go/+/220586 Reviewed-by: Dmitri Shuralyov (cherry picked from commit ba093c4562e7464e95a4bde6505d270b71ed623f) Reviewed-on: https://go-review.googlesource.com/c/go/+/221019 Run-TryBot: Dmitri Shuralyov TryBot-Result: Gobot Gobot --- diff --git a/doc/articles/race_detector.html b/doc/articles/race_detector.html index 1c449da5c0..014411d948 100644 --- a/doc/articles/race_detector.html +++ b/doc/articles/race_detector.html @@ -395,3 +395,14 @@ func (w *Watchdog) Start() { The cost of race detection varies by program, but for a typical program, memory usage may increase by 5-10x and execution time by 2-20x.

+ +

+The race detector currently allocates an extra 8 bytes per defer +and recover statement. Those extra allocations are not recovered until the goroutine +exits. This means that if you have a long-running goroutine that is +periodically issuing defer and recover calls, +the program memory usage may grow without bound. These memory allocations +will not show up in the output of runtime.ReadMemStats or +runtime/pprof. +