-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Prevent timer leaks in Workerpool and others #11333
Prevent timer leaks in Workerpool and others #11333
Conversation
There is a memory leak in `Workerpool` due to the intricacies of `time.Timer` stopping. Whenever a `time.Timer` is `Stop`ped its channel must be cleared using a `select` if the result of the `Stop()` is `false`. Unfortunately in `Workerpool` these were checked the wrong way round. However, there were a few other places that were not being checked. Signed-off-by: Andrew Thornton <[email protected]>
Signed-off-by: Andrew Thornton <[email protected]>
🚀 |
I suspect some of these drains might be able to go away to simplify things -- according to https://sourcegraph.com/github.com/golang/go/-/commit/ba3149612f62c011765876d7a437095fa50e0771 and some clarification on IRC, draining the channel isn't to prevent a leak within the channel but to attempt prevention of a false-positive on a consumer of the timer. So the two situations you'd actually be required to drain it are: 1.) If you're going to subsequently Reset() the timer, or I think the majority of these consumers fall into neither, as the timer's oftentimes only consumed by the single channel and not getting re-used. |
make lg-tm work |
There is a potential memory leak in `Workerpool` due to the intricacies of `time.Timer` stopping. Whenever a `time.Timer` is `Stop`ped its channel must be cleared using a `select` if the result of the `Stop()` is `false`. Unfortunately in `Workerpool` these were checked the wrong way round. However, there were a few other places that were not being checked. Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: techknowlogick <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
There is a potential memory leak in `Workerpool` due to the intricacies of `time.Timer` stopping. Whenever a `time.Timer` is `Stop`ped its channel must be cleared using a `select` if the result of the `Stop()` is `false`. Unfortunately in `Workerpool` these were checked the wrong way round. However, there were a few other places that were not being checked. Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: techknowlogick <[email protected]> Co-authored-by: Lunny Xiao <[email protected]> Co-authored-by: techknowlogick <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
There is a potential memory leak in `Workerpool` due to the intricacies of `time.Timer` stopping. Whenever a `time.Timer` is `Stop`ped its channel must be cleared using a `select` if the result of the `Stop()` is `false`. Unfortunately in `Workerpool` these were checked the wrong way round. However, there were a few other places that were not being checked. Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: techknowlogick <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
There is a memory leak in
Workerpool
due to the intricacies oftime.Timer
stopping.Whenever a
time.Timer
isStop
ped its channel must be cleared using aselect
if the result of theStop()
isfalse
.Unfortunately in
Workerpool
these were checked the wrong way round.However, there were a few other places that were not being checked.
Signed-off-by: Andrew Thornton [email protected]