Fix re-locking hang found in issue 86684 #88539
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
jprotze
approved these changes
Apr 12, 2024
|
Thank you! |
bazuzi
pushed a commit
to bazuzi/llvm-project
that referenced
this pull request
Apr 15, 2024
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 useskmpc_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 ofkmpc_malloc()/kmpc_free().KMP_INTERNAL_MALLOCandKMP_INTERNAL_FREEdo not use any bootstrap locks. They just translate tomalloc()/free()and are meant to be used during library initialization before other library-specific allocators have been initialized.Fixes: #86684