To answer the original question about how to detect the leak: if you have a leak, the “goroutine” profile from runtime/pprof <https://golang.org/pkg/runtime/pprof/#Profile> will show an ever-increasing number of goroutines with the same stack trace.
Detecting such a leak in a unit or integration test, however, is fairly tricky: you can fairly easily detect that the goroutine count is increasing, but it can be tricky to figure out whether that is a leak or just a transient increase while the program spools up to a steady state. On Thursday, April 5, 2018 at 4:53:21 PM UTC-4, T L wrote: > > > > On Thursday, April 5, 2018 at 3:32:53 AM UTC-4, Jan Mercl wrote: >> >> On Thu, Apr 5, 2018 at 9:10 AM T L <tapi...@gmail.com> wrote: >> >> > yes. it is a resource leak. >> >> It's not necessarily a leak. It's a possible leak. >> >> And digging even deeper: it's implementation defined. Non-reachable >> channels can be collected and goroutines blocked on them killed without >> changing the semantics of the program. >> -- >> >> -j >> > > There is an issue to do this, but it is denied. > https://github.com/golang/go/issues/19702 > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
