[llvm-bugs] [Bug 43565] New: Cannot call OpenMP functions from libiomp after calling from libomp

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43565

            Bug ID: 43565
           Summary: Cannot call OpenMP functions from libiomp after
                    calling from libomp
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Runtime Library
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremie.du-boisberranger at inria.fr
                CC: llvm-bugs at lists.llvm.org

Created attachment 22627
  --> https://bugs.llvm.org/attachment.cgi?id=22627&action=edit
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191004/bf8ff892/attachment.html>