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
As reported in https://reviews.llvm.org/D96893, the test
openmp/runtime/test/ompt/tasks/task_if0-depend.c leads to an assertion, when the runtime is built in debug mode (the test triggers a KMP_DEBUG_ASSERT).
Adding KMP_ASSERT(node.dn.nrefs==1); at the end of the __kmpc_omp_wait_deps function reveals, that some depnodes still have references to the depnode representing the task if0 dependency node. These depnodes will try to release the stack-allocated depnode object, after it was destroyed by returning from __kmpc_omp_wait_deps.
It might be necessary to replace the stack allocation by heap allocation.
The text was updated successfully, but these errors were encountered:
Better fix would be to not put stack-allocated node into dep hash, so that no references remained once the dependency is satisfied. Once this is barrier-like action, the node is not needed after the __kmpc_omp_wait_deps call.
Extended Description
As reported in https://reviews.llvm.org/D96893, the test
openmp/runtime/test/ompt/tasks/task_if0-depend.c leads to an assertion, when the runtime is built in debug mode (the test triggers a KMP_DEBUG_ASSERT).
Adding
KMP_ASSERT(node.dn.nrefs==1);
at the end of the__kmpc_omp_wait_deps
function reveals, that some depnodes still have references to the depnode representing the task if0 dependency node. These depnodes will try to release the stack-allocated depnode object, after it was destroyed by returning from__kmpc_omp_wait_deps
.It might be necessary to replace the stack allocation by heap allocation.
The text was updated successfully, but these errors were encountered: