Test test_arena_constraints sporadically hangs on Apple Silicon
#756
Comments
|
It seems we have two issues:
|
M1 Max has 10 cores (2 efficient and 8 performance cores) |
Thank you for the info, I was thinking about 8 cores, so the assumption above is not correct. |
|
Any news? |
|
It seems the testing approach is broken on ARM, any test using |
|
Is there any news on this issue? |
|
@alexey-katranov I changed the test_arena_constraints test: oneTBB/test/tbb/test_arena_constraints.cpp Lines 112 to 150 in 8155aae
TEST_CASE("Test memory leaks") {
constexpr size_t num_trials = 1000;
// To reduce the test session time only one constraints object is used inside this test.
// This constraints should use all available settings to cover the most part of tbbbind functionality.
auto constraints = tbb::task_arena::constraints{}
.set_numa_id(tbb::info::numa_nodes().front())
.set_core_type(tbb::info::core_types().front())
.set_max_threads_per_core(1);
std::mutex m;
size_t current_memory_usage = 0, previous_memory_usage = 0, stability_counter = 0;
bool no_memory_leak = false;
for (size_t i = 0; i < num_trials; i++) {
{ /* All DTORs must be called before GetMemoryUsage() call*/
tbb::task_arena arena{constraints};
arena.execute([&m]{
// ---
auto max_concurrency = tbb::this_task_arena::max_concurrency();
std::cerr << std::endl << std::endl << max_concurrency << std::endl << std::endl;
std::barrier barrier(tbb::this_task_arena::max_concurrency());
// utils::SpinBarrier barrier;
// barrier.initialize(tbb::this_task_arena::max_concurrency());
// ---
tbb::parallel_for(
tbb::blocked_range<size_t>(0, tbb::this_task_arena::max_concurrency()),
[&barrier, &m](const tbb::blocked_range<size_t>&r) {
// ----
auto s = r.end()-r.begin();
(void)m;
// m.lock();
if (s != 1) {
std::cerr << "\nInvalid chunk!!!\n";
abort();
}
// std::cerr << r.begin() << "|" << std::flush;
std::cerr << r.begin() << std::endl;
// m.unlock();
barrier.arrive_and_wait();
// barrier.wait();
// ----
}
);
// ----
std::cerr << "END" << std::endl;
// ----
});
}
current_memory_usage = utils::GetMemoryUsage();
stability_counter = current_memory_usage==previous_memory_usage ? stability_counter + 1 : 0;
// If the amount of used memory has not changed during 5% of executions,
// then we can assume that the check was successful
if (stability_counter > num_trials / 20) {
no_memory_leak = true;
break;
}
previous_memory_usage = current_memory_usage;
}
REQUIRE_MESSAGE(no_memory_leak, "Seems we get memory leak here.");
}Run test: Output 1: First trial - all threads are called (10). Second trial - the last thread is not called (only 9). Output 2: Last trial - the last thread is not called (only 9 digits is printed). |
|
Hi @phprus, the problem that Alex did not write all details that were behind the scene. |
|
@pavelkumbrasev On ARM this error occurs very frequently. On average, for a test to fail, it needs to be run less than 50 times. I'm think the issue #712 might have the same reasons. And this issue is reproduced on x86. In addition, for the |
|
This problem generally similar to reduced example: std::atomic<int> counter{0};
tbb::task_group g;
g.run([&] { ++counter; });
while (counter == 0);This example might hang on any system because oneTBB doesn't guaranteed parallelism and |
|
@pavelkumbrasev |
As you can see sometimes it is not true. |
|
@pavelkumbrasev @isaevil |
|
@pavelkumbrasev @phprus |
|
@isaevil |
|
@phprus is this issue still relevant? |
|
@nofuturre |
|
By the way, if you have any other ideas you are welcomed to put them into PR. |
Commit: cd6a5f9
Compiler:
Debug build.
Test output:
lldb:
The text was updated successfully, but these errors were encountered: