We should also document whether constructing your own timer manually is supported. In my own code, I have always done:

t := time.NewTimer(0)
<-t.C

since I was not sure whether manual construction was supported or not.

Alright, I can confirm that this CL https://go-review.googlesource.com/34784 aka commit 76f4fd8 at 76f4fd8#diff-67606dc98d3216ed00b49367a70885ecL128 introduced this bug.
Particularly the runtime code for delTimer, we previously found the timer to stop from the global slice of running timers, but now we are trying to delete a timer from a timersBucket of the provided ticker, yet invoking &time.Ticker{C: c} skips the setup in which runtime.startTimer creates and sets the appropriate *timersBucket to set in the runtimeTimer for each new Ticker.

/cc @valyala

CL coming up in a few minutes.

Change https://golang.org/cl/63970 mentions this issue: runtime, time: lazily assign a runtimeBucket before Stop

@odeke-em, with all due respect &time.Ticker{C: c} creates a ticker with a zero value timer, and the timer can't be started, correct? When Stop() is called, would it not be better to do nothing? In other words, return early if the timer is stopped, rather than lazily starting the timer only in order to stop it?

@mdcnz that's polite of you. No worries, it's a great question, and that's the purpose of healthy discourse, thank you for the comment!

In deed, it creates a zero value timer, and like yours, @ianlancetaylor also suggested the same on the review. My rationale for following the entire addtimer routine was to preserve an almost similar code path to the former code(since that's what it did before), and ensure that the runtimeBucket indexed by the goroutine's ID was being cleaned up. However, I'll be updating the CL to follow yours and @ianlancetaylor same suggestion.

Thanks for your response @odeke-em, nice one.