[OpenMP] runtime might try to take the bootstrap lock twice and deadlock #86684
Comments
|
@llvm/issue-subscribers-openmp Author: Joachim (jprotze)
This was initially reported here (including stacktraces): https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield
If |
shiltian
changed the title
|
It would be fantastic if someone (more knowledgeable than I) could look into this. We've been manually killing the stuck processes every day for quite some time now, which is not a good time. The processes get locked with an infinite sched_yield() call that maxes out the CPU until we see it and manually kill it. |
|
@jpeyton52 can you look into this issue? |
This was initially reported here (including stacktraces): https://stackoverflow.com/questions/78183545/does-compiling- imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield If __kmp_register_library_startup detects that another instance of the library is present, __kmp_is_address_mapped is eventually called. It calls __kmp_str_format, which uses kmpc_alloc to allocate memory for the string. This function calls __kmp_entry_thread to access the thread-local memory pool, which seems a bad idea during initialization. This macro internally calls __kmp_get_global_thread_id_reg which set the bootstrap look at the beginning (before calling __kmp_register_library_startup). The fix is to use KMP_INTERNAL_MALLOC/FREE instead of kmpc_malloc/free. KMP_INTERNAL_MALLOC and KMP_INTERNAL_FREE do not use any bootstrap lock. They just translate to malloc()/free(). Fixes: llvm#86684
|
@caliguian, it may help to manually delete |
This was initially reported here (including stacktraces): https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield If `__kmp_register_library_startup()` detects that another instance of the library is present, `__kmp_is_address_mapped()` is eventually called. which uses `kmpc_alloc()` to allocate memory. This function calls `__kmp_entry_thread()` to access the thread-local memory pool, which is a bad idea during initialization. This macro internally calls `__kmp_get_global_thread_id_reg()` which sets the bootstrap lock at the beginning (before calling `__kmp_register_library_startup()`). The fix is to use `KMP_INTERNAL_MALLOC()`/`KMP_INTERNAL_FREE()` instead of `kmpc_malloc()`/`kmpc_free()`. `KMP_INTERNAL_MALLOC` and `KMP_INTERNAL_FREE` do not use any bootstrap locks. They just translate to `malloc()`/`free()` and are meant to be used during library initialization before other library-specific allocators have been initialized. Fixes: #86684
|
@jpeyton52 Thank you! |
This was initially reported here (including stacktraces): https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield If `__kmp_register_library_startup()` detects that another instance of the library is present, `__kmp_is_address_mapped()` is eventually called. which uses `kmpc_alloc()` to allocate memory. This function calls `__kmp_entry_thread()` to access the thread-local memory pool, which is a bad idea during initialization. This macro internally calls `__kmp_get_global_thread_id_reg()` which sets the bootstrap lock at the beginning (before calling `__kmp_register_library_startup()`). The fix is to use `KMP_INTERNAL_MALLOC()`/`KMP_INTERNAL_FREE()` instead of `kmpc_malloc()`/`kmpc_free()`. `KMP_INTERNAL_MALLOC` and `KMP_INTERNAL_FREE` do not use any bootstrap locks. They just translate to `malloc()`/`free()` and are meant to be used during library initialization before other library-specific allocators have been initialized. Fixes: llvm#86684
This was initially reported here (including stacktraces): https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield
If
__kmp_register_library_startupdetects that another instance of the library is present,__kmp_is_address_mappedis eventually called. It calles__kmp_str_format, which useskmpc_allocto allocate memory for the string. This function calls__kmp_entry_threadto access the thread-local memory pool, which seems a bad idea during initialization. This macro internally calls__kmp_get_global_thread_id_regwhich set the bootstrap look at the beginning (before calling__kmp_register_library_startup).The text was updated successfully, but these errors were encountered: