https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556
Bug ID: 111556
Summary: OMP_* environment variables not read if libgomp is
loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the
process executable access the environ global variable
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: silvio at traversaro dot it
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 55976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55976&action=edit
Self-contained example demonstrating the problem, just execute the run script
to reproduce the problem.
I am not 100% sure if this is a problem in libgomp, but given this was
something that worked fine in libgomp <=12 and it was not trivial to understand
what was going on, I prefer to report it in the libgomp bugzilla, so that
future users encountering this problem have a reference.
If the following conditions occur:
* libgomp is loaded in a process via a call to dlopen([..], [..]|RTLD_DEEPBIND)
* the process executable access the environ global variable
then during libgomp's loading the OMP_* environment variables are ignored.
The problem is demonstrated with the attached example. In the attached example
a main is loading a shared library lib.so, and lib.so links libgomp, and the
OMP_CANCELLATION env variable is set to true. If the main does not access the
environ global variable, then OMP_CANCELLATION env variable is correctly loaded
(i.e. omp_get_cancellation() returns 1), while if the main access the environ
global variable, the OMP_CANCELLATION variable is ignored (i.e.
omp_get_cancellation() returns 0). Running the same example against libgomp <=
12, in both cases the OMP_CANCELLATION variable is correctly read (i.e.
omp_get_cancellation() returns 1).
Why is this happening? I am not an expert so I may be getting something wrong,
but what I understood in my debugging (see
https://github.com/conda-forge/casadi-feedstock/issues/93#issuecomment-1732344044
for the downstream issue), is that in the case in which the executable is
directly accessing the environ variable, a copy of the environ global variable
(that in all other cases is in the bss of glibc shared library, as a weak
symbol) is placed in the bss of the executable, as strong symbol. That means
that in the process there are two different environ symbols. In normal
conditions, only the environ in executable's bss is accessed by all libraries,
while the one in glibc's bss remains NULL initialized. However if gomp is
loaded via RTLD_DEEPBIND, when gomp tries to access environ, it access the
glibc's environ, that was never initialized and so it is still NULL. I am not
sure if this is an intended behavior, see also the related glibc issue
https://sourceware.org/bugzilla/show_bug.cgi?id=9758 .
Interestingly, if one access the environment via glibc's functions such as
getenv or similar, everything works fine, as glibc for sure is not loaded via
RTLD_DEEPBIND, and so in its functions environ is resolved to the correct
environ, i.e. the one of the executable's bss. I think this is the reason why
everything works fine with gomp <= 12, as before gomp 13 the environ variable
was not directly accessed in gomp.
