x/time: possible race in rate/Limiter.WaitN leading to Timer being leaked

[toby-jn]

What version of Go are you using (go version)?

$ go version
go version go1.12.9 linux/amd64

github.com/golang/time: 9d24e82272b4f38b78bc8cff74fa936d31ccd8ef

Does this issue reproduce with the latest release?

Yes

What did you do?

Looking at the code for the rate limiter, in WaitN https://github.com/golang/time/blob/9d24e82272b4f38b78bc8cff74fa936d31ccd8ef/rate/rate.go#L252 the return value of t.Stop() is not checked, if the timer expired between the context being cancelled and the defer being executed then this timer will be blocked sending on t.C and I believe will be leaked.

What did you expect to see?

Timer should be drained after calling Stop(), this should be done in the case <-ctx.Done()

What did you see instead?

Result of Stop() not checked and the timer potentially leaked.

[bcmills]

A time.Timer does not need to be drained to avoid leaks. (The Timer.C channel is buffered, and buffered channels can be GC'd even if there are values in the buffer.)

[bcmills]

I don't think there is a bug here, but please reopen if you observe a leak empirically.