You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug, including details regarding any error messages, version, and platform.
Some of the decimal benchmarks access their benchmark data in strides, without checking that the accesses fall withing bounds. Example here, where kValueSize (10) is actually not a multiple of 4:
…ccesses
A side effect is that this will break benchmark history because the previous iterations/s calculation was wrong, even though actual performance is unchanged.
#43212)
### Rationale for this change
Some of the decimal benchmarks access their benchmark data in strides, without checking that the accesses fall within bounds.
A side effect is that this will break benchmark history because the iterations/s calculation was wrong, even though actual performance is unchanged.
### Are these changes tested?
By the continuous benchmarking jobs.
### Are there any user-facing changes?
No.
* GitHub Issue: #43211
Authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: Antoine Pitrou <antoine@python.org>
Describe the bug, including details regarding any error messages, version, and platform.
Some of the decimal benchmarks access their benchmark data in strides, without checking that the accesses fall withing bounds. Example here, where
kValueSize
(10) is actually not a multiple of 4:arrow/cpp/src/arrow/util/decimal_benchmark.cc
Lines 89 to 98 in 5e451d8
This manifests in crashes on some of the macOS benchmark machines, and the issue can be reproduced locally using Valgrind:
$ ARROW_DEFAULT_MEMORY_POOL=system valgrind <build dir>/relwithdebinfo/arrow-decimal-benchmark --benchmark_repetitions=6 --benchmark_min_time=0.050000s
Component(s)
C++
The text was updated successfully, but these errors were encountered: