The OpenMP runtime crashes multi-threaded programs which call getenv(...)

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

Calling setenv from one thread while another thread calls getenv will cause a crash. The GLIBC manual ( ) 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: .

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?

Joel Daniels

Hi Joel Daniels,

thanks for reporting this. I put it on our agenda for the next weekly OpenMP in LLVM call, Wednesday 9am CDT:

Feel free to join if you are interested.


Given the documented issue with setenv/getenv here, it seems like KMP should use an alternative mechanism like POSIX shared memory or temp files that do not have the same issue.


Hi Joel,
    Todd tried to sent mail saying he is working on resolving this issue, seems like it did not make it to the distribution list. See his message below.