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

appender: fix incorrect compare_exchange when rolling #1989

Merged
merged 3 commits into from Mar 13, 2022

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Mar 12, 2022

This branch fixes a bug in RollingFileAppender where
compare_exchange is called with the current timestamp as the
"current value" of the next rollover timestamp, rather than the actual
current value. This means that if the current time is greater than the
rollover time, the CAS will fail and the appender will never roll over
--- currently, rolling only functions correctly if we try to write to
the file at precisely the rollover time. This means that, in practice,
the appender almost never rolls over.

I've fixed this by ensuring that the compare-and-swap is always
performed with the current value of the atomic, rather than the current
timestamp. should_rollover now returns an Option with the current
value in it to indicate it's time to roll over, so that we perform the
CAS with the value loaded in should_rollover.

I've also added a test that exercises a file rollover using a mock
time. This would have caught the bug.

Fixes #1987

This reproduces the bug described in #1987

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch fixes a bug in `RollingFileAppender` where
`compare_exchange` is called with the _current timestamp_ as the
"current value" of the next rollover timestamp, rather than the actual
current value. This means that if the current time is *greater* than the
rollover time, the CAS will fail and the appender will never roll over
--- currently, rolling only functions correctly if we try to write to
the file at *precisely* the rollover time. This means that, in practice,
the appender almost never rolls over.

I've fixed this by ensuring that the compare-and-swap is always
performed with the current value of the atomic, rather than the current
timestamp. `should_rollover` now returns an `Option` with the current
value in it to indicate it's time to roll over, so that we perform the
CAS with the value loaded in `should_rollover`.

Fixes #1987
@hawkw hawkw requested a review from a team as a code owner March 12, 2022 20:36
@hawkw hawkw enabled auto-merge (squash) March 12, 2022 21:53
@hawkw hawkw disabled auto-merge March 12, 2022 21:54
@hawkw hawkw enabled auto-merge (squash) March 13, 2022 00:40
@hawkw hawkw merged commit 1dc94fa into master Mar 13, 2022
@hawkw hawkw deleted the eliza/fix-next-date branch March 13, 2022 00:52
davidbarsky pushed a commit that referenced this pull request Mar 17, 2022
This branch fixes a bug in `RollingFileAppender` where
`compare_exchange` is called with the _current timestamp_ as the
"current value" of the next rollover timestamp, rather than the actual
current value. This means that if the current time is *greater* than the
rollover time, the CAS will fail and the appender will never roll over
--- currently, rolling only functions correctly if we try to write to
the file at *precisely* the rollover time. This means that, in practice,
the appender almost never rolls over.

I've fixed this by ensuring that the compare-and-swap is always
performed with the current value of the atomic, rather than the current
timestamp. `should_rollover` now returns an `Option` with the current
value in it to indicate it's time to roll over, so that we perform the
CAS with the value loaded in `should_rollover`.

I've also added a test that exercises a file rollover using a mock
time. This would have caught the bug described in #1987.

Fixes #1987

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw added a commit that referenced this pull request Mar 17, 2022
This branch fixes a bug in `RollingFileAppender` where
`compare_exchange` is called with the _current timestamp_ as the
"current value" of the next rollover timestamp, rather than the actual
current value. This means that if the current time is *greater* than the
rollover time, the CAS will fail and the appender will never roll over
--- currently, rolling only functions correctly if we try to write to
the file at *precisely* the rollover time. This means that, in practice,
the appender almost never rolls over.

I've fixed this by ensuring that the compare-and-swap is always
performed with the current value of the atomic, rather than the current
timestamp. `should_rollover` now returns an `Option` with the current
value in it to indicate it's time to roll over, so that we perform the
CAS with the value loaded in `should_rollover`.

I've also added a test that exercises a file rollover using a mock
time. This would have caught the bug described in #1987.

Fixes #1987

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw pushed a commit that referenced this pull request Mar 17, 2022
# 0.2.2 (March 17, 2022)

This release fixes an incorrect `compare_exchange` in RollingFileAppender 
when rolling files over, causing a panic.

### Fixed
- **rolling**: Fixed a panic that prohibited rolling files over. ([#1989])

[#1989]: #1989
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.

tracing-appender 0.2.1 panics while rolling in debug mod
2 participants