1. What version of Go are you using (go version)?
   go version go1.6.2 linux/amd64
2. What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/home/kelwert/go1.6.2"
GOTOOLDIR="/home/kelwert/go1.6.2/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?

We've been working at rolling out a go-based ssh server to replace some old infra and we noticed that after handling a few million connections, the memory usage seems to go up from about 6MB to 30MB over the course of a day. This obviously isn't a very large leak, but it's definitely noticeable over a long period of time.

After investigating, I think we've narrowed it down to the fact that the only function which closes the channel's request channel (*channel.close()) is never called if a connection dies early. It is only closed if the channel gets a msgChannelClose in *channel.handlePacket.

This leaves any server implementation using ssh.DiscardRequests open to a goroutine leak because the channel that function is ranging over never gets closed and therefore the goroutine never exits even when the underlying connection (and in extension, ssh-channel) is closed.

I don't have a simple example yet, as writing ssh server implementation is not simple and distilling a bug down to a reproducible case isn't easy, but I'll update this when I have one.

1. What did you expect to see?
   No memory leak.
2. What did you see instead?
   A very small memory leak.

Additional notes:

*channel.Close never actually calls *channel.close. It simply sends a msgChannelClose.