Hi OpenMP Dev Team,
On startup, the OpenMP runtime currently calls the libc function setenv. At that point the call stack looks like:
setenv: glibc
__kmp_env_set: https://github.com/llvm/llvm-project/blob/57b08b0944046a6a57ee9b7b479181f548a5b9b4/openmp/runtime/src/kmp_environment.cpp#L176
__kmp_register_library_startup: https://github.com/llvm/llvm-project/blob/cde8f4c164a27670ebe60a1969d486393336d778/openmp/runtime/src/kmp_runtime.cpp#L6383
Calling setenv from one thread while another thread calls getenv will cause a crash. The GLIBC manual ( https://www.gnu.org/software/libc/manual/html_node/Environment-Access.html#Environment-Access ) says:
"Modifications of environment variables are not allowed in multi-threaded programs."
Crashes related to setenv and getenv have been empirically observed by others, see for example: https://rachelbythebay.com/w/2017/01/30/env/ .
We have a multithreaded program which loads (via dlopen) a library which uses Intel's MKL library which in turn depends on the OpenMP runtime. We have observed random crashes in threads calling "getenv" which occur at the same time that another thread is initializing the OpenMP runtime.
We are currently looking at hacks (like LD_PRELOAD of a library that replaces getenv and setenv with threadsafe ones) to get around this but I thought we should flag the issue upstream to you guys as well.
OpenMP seems to be attempting to use environment variables as a method of identifying when multiple copies of the runtime have been loaded. I'm not sure under what scenarios this happens, but if such a guard is needed then I would hope this could be handled via a global mutex protected static symbol instead?
Thanks!
Joel Daniels