<pre class="notranslate">I'm seeing really weird GC behaviour when using the net/http package.

If I call a function that creates a bunch of garbage slices inside a ServeMux.HandleFunc
the issue rears its head. If I then also don't close the req.Body, the issue gets way
worse.

If I call the same function on its own, no memory is leaked. If I call the same function
in a goroutine and wait for it to finish, no memory is leaked either.

It seems like I'm doing something weird with net/http, or there's a bug lurking here.
I'm reporting this as I'm out of ideas.

go version:
go version devel +58f8a30f5b78 Tue Apr 16 14:20:06 2013 -0700 linux/amd64

uname -a:
Linux me 3.3.8-1.fc16.x86_64 #1 SMP Mon Jun 4 20:49:02 UTC 2012 x86_64 x86_64 x86_64
GNU/Linux

Code to reproduce is here:
<a href="http://play.golang.org/p/ALlr3_MzSX" rel="nofollow">http://play.golang.org/p/ALlr3_MzSX</a>

$ GOGCTRACE=1 go run ram_issue.go | grep gc</pre>
<pre class="notranslate">What steps will reproduce the problem?
1. ~/bug.go contains any program compiling successfully (e.g.
<a href="http://play.golang.org/p/RQT4BfIN7h)" rel="nofollow">http://play.golang.org/p/RQT4BfIN7h)</a>
2. go install ~/bug.go

Reading the documentation of "go install" I expect it to fail because ~/bug.go
is not an import path.

Instead this error message is logged: "go install: no install location for .go
files listed on command line (GOBIN not set)"

In any case there's a documentation in the bug, since there's no mention $GOBIN.

Once the expected behavior clarified I'm happy to try to fix it.</pre>