mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-11 05:33:47 +01:00
dc2f10bd81
If you had TIME_MAX > INT_MAX, and your "time_to_exhaust_bw = accountingmax/expected_bandwidth_usage * 60" calculation managed to overflow INT_MAX, then your time_to_consider value could underflow and wind up being rediculously low or high. "Low" was no problem; negative values got caught by the (time_to_consider <= 0) check. "High", however, would get you a wakeup time somewhere in the distant future. The fix is to check for time_to_exhaust_bw overflowing INT_MAX, not TIME_MAX: We don't allow any accounting interval longer than a month, so if time_to_exhaust_bw is significantly larger than 31*24*60*60, we can just clip it. This is a bugfix on 0.0.9pre6, when accounting was first introduced. It fixes bug 2146, unless there are other causes there too. The fix is from boboper. (I tweaked it slightly by removing an assignment that boboper marked as dead, and lowering a variable that no longer needed to be function-scoped.)
5 lines
228 B
Groff
5 lines
228 B
Groff
- Major bugfixes:
|
|
o Fix a bug that could break accounting on 64-bit systems with large
|
|
time_t values, making them hibernate for impossibly long intervals.
|
|
Bugfix on 0.0.9pre6; fix for bug 2146; fix by boboper.
|