diff options
author | Jonathan Peyton <jonathan.l.peyton@intel.com> | 2024-04-12 15:13:59 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-04-12 15:13:59 -0500 |
commit | 5300a6731e98fbcf7bca68374e934de737166698 (patch) | |
tree | 7f1d04e569aa3053fc12751b2fc3200e0d0c9998 /llvm/unittests/Support/VirtualFileSystemTest.cpp | |
parent | 41ff91e143a72dcd5755c9ad2160cf3c333b50c6 (diff) | |
download | llvm-5300a6731e98fbcf7bca68374e934de737166698.zip llvm-5300a6731e98fbcf7bca68374e934de737166698.tar.gz llvm-5300a6731e98fbcf7bca68374e934de737166698.tar.bz2 |
[OpenMP] Fix re-locking hang found in issue 86684 (#88539)
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
Diffstat (limited to 'llvm/unittests/Support/VirtualFileSystemTest.cpp')
0 files changed, 0 insertions, 0 deletions