A pointer to this variable is used in a call to memory::RegisterCopyStorageBufferBenchmark().
|
double avg_latency_seconds = 0; |
|
memory::RegisterCopyStorageBufferBenchmark( |
|
gpu_name, device, num_bytes, shader, latency_measure->mode, |
|
&latency_measure->overhead_seconds, &avg_latency_seconds); |
Since this is a local automatic variable, it goes out of scope and the pointer used to register the benchmark points to some place on the stack that will later be used for subsequent stack frames. Later, when the benchmark actually runs, this code:
|
*avg_latency_seconds = total_seconds / state.iterations(); |
writes a double to some unwanted place on the stack, causing corruption.
I only saw this problem on LLVM/Clang and didn't see it with MSVC or GCC compilers. The failures are somewhat random as is the case with these stack corruption problems. In my case with LLVM, I got a seg fault as the code returned from running the benchmark.
The easiest fix is to just change the storage class of avg_latency_seconds to static. It doesn't look like this variable is actually used or reported anywhere, so it could be removed from the benchmark parameter list (and registration) entirely, or perhaps make a space for it in a benchmark-related data structure that has a lifetime that spans the execution of the test.
A pointer to this variable is used in a call to
memory::RegisterCopyStorageBufferBenchmark().uVkCompute/benchmarks/memory/copy_storage_buffer_main.cc
Lines 41 to 44 in 2e4c8e4
Since this is a local automatic variable, it goes out of scope and the pointer used to register the benchmark points to some place on the stack that will later be used for subsequent stack frames. Later, when the benchmark actually runs, this code:
uVkCompute/benchmarks/memory/copy_storage_buffer.cc
Line 221 in 2e4c8e4
writes a double to some unwanted place on the stack, causing corruption.
I only saw this problem on LLVM/Clang and didn't see it with MSVC or GCC compilers. The failures are somewhat random as is the case with these stack corruption problems. In my case with LLVM, I got a seg fault as the code returned from running the benchmark.
The easiest fix is to just change the storage class of
avg_latency_secondsto static. It doesn't look like this variable is actually used or reported anywhere, so it could be removed from the benchmark parameter list (and registration) entirely, or perhaps make a space for it in a benchmark-related data structure that has a lifetime that spans the execution of the test.