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:
|
for (int x = 0; x < kValueSize; x += 4) { |
|
auto equal = v1[x] == v2[x]; |
|
benchmark::DoNotOptimize(equal); |
|
auto less_than_or_equal = v1[x + 1] <= v2[x + 1]; |
|
benchmark::DoNotOptimize(less_than_or_equal); |
|
auto greater_than_or_equal1 = v1[x + 2] >= v2[x + 2]; |
|
benchmark::DoNotOptimize(greater_than_or_equal1); |
|
auto greater_than_or_equal2 = v1[x + 3] >= v1[x + 3]; |
|
benchmark::DoNotOptimize(greater_than_or_equal2); |
|
} |
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++
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.050000sComponent(s)
C++