Skip to content

Fix incorrect usage of Timer.Reset, honour Context deadlines, avoid leaking timers#1

Open
cPu1 wants to merge 4 commits intomasterfrom
timer-reset-fix
Open

Fix incorrect usage of Timer.Reset, honour Context deadlines, avoid leaking timers#1
cPu1 wants to merge 4 commits intomasterfrom
timer-reset-fix

Conversation

@cPu1
Copy link
Copy Markdown
Owner

@cPu1 cPu1 commented Jan 3, 2024

What?

TODO: open this PR in the upstream repo after reviewing the contribution guidelines.

I came across this while going through the codebase.

This changelist includes three changes:

  • Fix incorrect usage of Timer.Reset.
  • Honour Context deadlines, including for http.Request.
  • Avoid leaking timers.

There are a few places in the codebase where Timer.Reset is being called right before attempting to receive from the
Timer.C channel. If the timer has already fired, this can lead to a receive from Timer.C returning earlier than
the duration supplied to Timer.Reset as Reset does not drain the Timer.C channel.

Here's an example to demonstrate this:

timer := time.NewTimer(100 * time.Millisecond)
time.Sleep(200 * time.Millisecond)
timer.Reset(24 * time.Hour)
select {
case <-time.After(1 * time.Millisecond):
case <-timer.C:
  panic("fired before 24 hours")
}

It's not advisable to call Timer.Reset while it's still active on a Timer obtained from a call to time.NewTimer,
as mentioned in the docs. The correct usage is to call Reset only on timers
that are stopped or have had their channels drained.

This changelist fixes the issue by creating a new Timer before waiting on Timer.C, and Stopping it before the function returns.

Why?

Checklist

  • I have performed a self-review of my code.
  • I have added tests for my changes.
  • I have run linter locally (make lint) and all checks pass.
  • I have run tests locally (make tests) and all tests pass.
  • I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

cPu1 added 4 commits January 3, 2024 18:52
There are a few places in the codebase where `Timer.Reset` is being called right before attempting to receive from the
`Timer.C` channel. If the timer has already fired, this can lead to a receive from `Timer.C` returning earlier than
the duration supplied to `Timer.Reset` as `Reset` does not drain the `Timer.C` channel.

Here's an example to demonstrate this:

```golang
timer := time.NewTimer(100 * time.Millisecond)
time.Sleep(200 * time.Millisecond)
timer.Reset(24 * time.Hour)
select {
case <-time.After(1 * time.Millisecond):
case <-timer.C:
  panic("fired before 24 hours")
}
```

Additionally, it's not advisable to call `Timer.Reset` while it's still active on a `Timer` obtained from a call to `time.NewTimer`,
as mentioned in the [docs](https://pkg.go.dev/time#Timer.Reset). The correct usage is to call `Reset` only on timers
that are stopped or have had their channels drained.

This changelist fixes the issue by creating a new `Timer` before waiting on `Timer.C` and `Stop`ping it before the function returns.
Some parts of the codebase do not call `Timer.Stop`, leaking the underlying `Timer` if it has not already fired.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant