LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 43565 - Cannot call OpenMP functions from libiomp after calling from libomp
Summary: Cannot call OpenMP functions from libiomp after calling from libomp
Status: NEW
Alias: None
Product: OpenMP
Classification: Unclassified
Component: Runtime Library (show other bugs)
Version: unspecified
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-04 06:50 PDT by Jeremie du Boisberranger
Modified: 2020-09-01 11:04 PDT (History)
2 users (show)

See Also:
Fixed By Commit(s):


Attachments
test program (846 bytes, text/x-csrc)
2019-10-04 06:50 PDT, Jeremie du Boisberranger
Details
correct test program (743 bytes, text/x-csrc)
2019-10-04 07:03 PDT, Jeremie du Boisberranger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremie du Boisberranger 2019-10-04 06:50:37 PDT
Created attachment 22627 [details]
test program

Hi,

when a program loads both libiomp and libomp with dlopen, calling an OpenMP function from one then from the other one can cause the program to terminate, depending on the order of the calls.

calling from libiomp first, then from libomp is fine. The issue is when calling from libomp first and then from libiomp.

I attached a reproducing example (test.c)
to reproduce:
clang test.c -o test -ldl && ./test


Error:
OMP: Error #13: Assertion failure at z_Linux_util.cpp(2338).
OMP: Hint Please submit a bug report with this message, compile and run commands used, and machine configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see http://www.intel.com/software/products/support/.


Backtrace:
#0  0x00007ffff783e428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff784002a in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6f7b2c3 in __kmp_abort_process () at ../../src/kmp_runtime.cpp:481
#3  0x00007ffff6f66237 in __kmp_fatal (message=...) at ../../src/kmp_i18n.cpp:894
#4  0x00007ffff6f3a82c in __kmp_debug_assert (msg=0x76c5 <error: Cannot access memory at address 0x76c5>, 
    file=0x76c5 <error: Cannot access memory at address 0x76c5>, line=6) at ../../src/kmp_debug.cpp:100
#5  0x00007ffff6fb57ee in __kmp_is_address_mapped (addr=0x76c5) at ../../src/z_Linux_util.cpp:2337
#6  0x00007ffff6f78f87 in __kmp_register_library_startup () at ../../src/kmp_runtime.cpp:6684
#7  0x00007ffff6f7a49b in _INTERNAL_25_______src_kmp_runtime_cpp_ddfed41b::__kmp_do_serial_initialize ()
    at ../../src/kmp_runtime.cpp:6834
#8  _INTERNAL_25_______src_kmp_runtime_cpp_ddfed41b::__kmp_do_middle_initialize () at ../../src/kmp_runtime.cpp:7146
#9  __kmp_middle_initialize () at ../../src/kmp_runtime.cpp:7255
#10 0x00007ffff6f5ad75 in __kmp_api_omp_get_max_threads () at ../../src/kmp_ftn_entry.h:366
#11 0x00000000004006ab in main ()


Some remarks:
- Based on the error message, the issue seems to come from libiomp. I still post here because it's caused by its interaction with libomp (and both are essentially the same). I'll also report it to intel.

- Loading libgomp instead of libomp does not raise the error

- Include libraries instead of dlopen does not raise the error

- I know it's bad practice to load different OpenMP runtimes simultaneously. And in fact I have to set KMP_DUPLICATE_LIB_OK=TRUE otherwise it does not work at all. But in the python ecosystem, you can easily install packages from pre-built binaries and we don't know in advance which compiler has been used. For instance if one package uses MKL and another one uses OpenMP and is built with clang.


Thanks
Comment 1 Jeremie du Boisberranger 2019-10-04 07:03:16 PDT
Created attachment 22628 [details]
correct test program
Comment 2 Jeremie du Boisberranger 2019-10-04 07:04:45 PDT
Another remark: the order of the dlopen does not matter.