Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A potential goroutine memory leak #1477

Open
xuxiaofan1203 opened this issue Mar 26, 2024 · 2 comments
Open

A potential goroutine memory leak #1477

xuxiaofan1203 opened this issue Mar 26, 2024 · 2 comments

Comments

@xuxiaofan1203
Copy link

xuxiaofan1203 commented Mar 26, 2024

Hello, I found a potential bug when I used the project, I'm not sure I'm right, we can discuss the problem to avoid a potential trouble possibly.

Blocking position:


At line 449 call the wg.Add(goroutineBudget), and wg.Wait() is blocked until wg.Done() is called the number of goroutineBudget times to awaken the wg.Wait().
But if the select statement chooses the default path, return the function, maybe the wg.Done() has not executed enough times to awaken the wg.Wait(), which can result in a goroutine leak
collectWorker := func() {
for {
select {
case collector := <-checkedCollectors:
collector.Collect(checkedMetricChan)
case collector := <-uncheckedCollectors:
collector.Collect(uncheckedMetricChan)
default:
return
}
wg.Done()
}
}

Complete codes of the part
wg.Add(goroutineBudget)
collectWorker := func() {
for {
select {
case collector := <-checkedCollectors:
collector.Collect(checkedMetricChan)
case collector := <-uncheckedCollectors:
collector.Collect(uncheckedMetricChan)
default:
return
}
wg.Done()
}
}
// Start the first worker now to make sure at least one is running.
go collectWorker()
goroutineBudget--
// Close checkedMetricChan and uncheckedMetricChan once all collectors
// are collected.
go func() {
wg.Wait()
close(checkedMetricChan)
close(uncheckedMetricChan)
}()

@xuxiaofan1203 xuxiaofan1203 changed the title A potential goroutine leak due to misusing waitgroup A potential goroutine memory leak Apr 4, 2024
@ArthurSens
Copy link
Member

ArthurSens commented May 13, 2024

I guess we could test this behavior using the runtime package? More precisely, using runtime.NumGoroutine()(https://pkg.go.dev/runtime#NumGoroutine)

Verify the number of goroutines, execute the function you believe there is a leak, and verify the number of go routines again. If numbers are different, it means we have a leak :)

@bwplotka
Copy link
Member

bwplotka commented Jul 8, 2024

As @kakkoyun suggested, we can double check with https://github.com/uber-go/goleak. Help wanted to add this (if not added before) (:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants