[Bug libgomp/111556] New: OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

[Bug libgomp/111556] New: OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

[silvio at traversaro dot it]

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.

[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-linux-gnu
          Component|libgomp                     |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
As mentioned in the glibc bug report, it is only an issue on targets which use
copy relocs which means it is an x86_64 only issue as I think that is the only
target that uses copy relocs still ...

[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And I doubt there is anything we can do about this on the libgomp side. 
Because of the OpenMP standard changes, we simply need to scan all the
environmental variable names and check them for some cases, we can't just use
getenv anymore, because relevant variables can have just some prefix plus
numerical suffix and calling getenv 2G+ times for each prefix is not feasible.

[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

[silvio at traversaro dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556

--- Comment #3 from Silvio Traversaro <silvio at traversaro dot it> ---
Thanks for the quick reply! I imagined something like that, but I preferred
anyhow to have a clear bug on the libgomp so that I can refer to it and for
other people that could encounter this behavior. 

Feel free to close as WONTFIX, thanks again!

[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

[gnu.org at hovland dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556

Jay <gnu.org at hovland dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gnu.org at hovland dot cx

--- Comment #4 from Jay <gnu.org at hovland dot cx> ---
Hi,

I am using PHP with an extension imagick.
PHP loads this extension with dlopen() and flag RTLD_DEEPBIND.
At some point libgomp gets loaded in this process.
During libgomp and initialize_env(), the process crashes because environ is
probably not initialised yet causing line 2062 in env.c to crash at:

<<< for (env = environ; *env != 0; env++)


Loading the same extension without deepbind solves the problem since I guess
the environ-variable gets overloaded/set by calling code, but perhaps you could
add a non-NULL test ? It would probably solve the problem when using deepbind.

[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The not dereferencing NULL environ is PR111413 and has been fixed already.
That is something different from what is reported here, and as I said, there is
nothing that can be done about it except "don't do it".