qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-11 20:50:23 -07:00
Code Releases Activity

doc/articles/race_detector: mention memory leak potential

Browse Source 
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 <dmitshur@golang.org>
This commit is contained in:
Kevin Burke 2020-02-23 20:45:51 -08:00
parent 490bc6097a
commit ba093c4562
1 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
doc/articles/race_detector.html
View File

@ -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.
</p>
<p>
The race detector currently allocates an extra 8 bytes per <code>defer</code>
and <code>recover</code> statement. Those extra allocations <a
href="https://golang.org/issue/26813">are not recovered until the goroutine
exits</a>. This means that if you have a long-running goroutine that is
periodically issuing <code>defer</code> and <code>recover</code> calls,
the program memory usage may grow without bound. These memory allocations
will not show up in the output of <code>runtime.ReadMemStats</code> or
<code>runtime/pprof</code>.
</p>