[all-commits] [llvm/llvm-project] 5300a6: [OpenMP] Fix re-locking hang found in issue 86684 ...

[Jonathan Peyton via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5300a6731e98fbcf7bca68374e934de737166698
      https://github.com/llvm/llvm-project/commit/5300a6731e98fbcf7bca68374e934de737166698
  Author: Jonathan Peyton <jonathan.l.peyton at intel.com>
  Date:   2024-04-12 (Fri, 12 Apr 2024)

  Changed paths:
    M openmp/runtime/src/z_Linux_util.cpp

  Log Message:
  -----------
  [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



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications