[Bug libgomp/109634] New: Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[Bug libgomp/109634] New: Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[gcc_bugzilla at murphyslantech dot de]

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

            Bug ID: 109634
           Summary: Linking Imagick for PHP compiles fine but gives
                    segfault caused by libgomp on runtime
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc_bugzilla at murphyslantech dot de
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

When compiling the imagick (ImageLibrary to use ImageMagick in PHP) this
compiles fine (no errors only warnings), but the resulting extension is not
working, causing php to crash with a segfault. Disabling the extension again,
everything works as expected (except that functions from the extension are not
available).

The error is also tracked here: https://github.com/Imagick/imagick/issues/609,
but basically this boils down to:

==272669== Memcheck, a memory error detector
==272669== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==272669== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==272669== Command: php -v
==272669== 
==272669== Invalid read of size 8
==272669==    at 0x908AADE: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==272669==    by 0x400533D: call_init.part.0 (dl-init.c:70)
==272669==    by 0x4005427: call_init (dl-init.c:33)
==272669==    by 0x4005427: _dl_init (dl-init.c:117)
==272669==    by 0x4001561: _dl_catch_exception (dl-catch.c:211)
==272669==    by 0x400C345: dl_open_worker (dl-open.c:808)
==272669==    by 0x400C345: dl_open_worker (dl-open.c:771)
==272669==    by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==    by 0x400C6BB: _dl_open (dl-open.c:884)
==272669==    by 0x5303BEB: dlopen_doit (dlopen.c:56)
==272669==    by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==    by 0x4001602: _dl_catch_error (dl-catch.c:256)
==272669==    by 0x53036BE: _dlerror_run (dlerror.c:138)
==272669==    by 0x5303CA0: dlopen_implementation (dlopen.c:71)
==272669==    by 0x5303CA0: dlopen@@GLIBC_2.34 (dlopen.c:81)
==272669==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==272669== 
==272669== 
==272669== Process terminating with default action of signal 11 (SIGSEGV)
==272669==  Access not within mapped region at address 0x0
==272669==    at 0x908AADE: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==272669==    by 0x400533D: call_init.part.0 (dl-init.c:70)
==272669==    by 0x4005427: call_init (dl-init.c:33)
==272669==    by 0x4005427: _dl_init (dl-init.c:117)
==272669==    by 0x4001561: _dl_catch_exception (dl-catch.c:211)
==272669==    by 0x400C345: dl_open_worker (dl-open.c:808)
==272669==    by 0x400C345: dl_open_worker (dl-open.c:771)
==272669==    by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==    by 0x400C6BB: _dl_open (dl-open.c:884)
==272669==    by 0x5303BEB: dlopen_doit (dlopen.c:56)
==272669==    by 0x40014DC: _dl_catch_exception (dl-catch.c:237)
==272669==    by 0x4001602: _dl_catch_error (dl-catch.c:256)
==272669==    by 0x53036BE: _dlerror_run (dlerror.c:138)
==272669==    by 0x5303CA0: dlopen_implementation (dlopen.c:71)
==272669==    by 0x5303CA0: dlopen@@GLIBC_2.34 (dlopen.c:81)
==272669==  If you believe this happened as a result of a stack
==272669==  overflow in your program's main thread (unlikely but
==272669==  possible), you can try to increase the size of the
==272669==  main thread stack using the --main-stacksize= flag.
==272669==  The main thread stack size used in this run was 8388608.
==272669== 
==272669== HEAP SUMMARY:
==272669==     in use at exit: 1,105,972 bytes in 6,392 blocks
==272669==   total heap usage: 7,187 allocs, 795 frees, 1,359,342 bytes
allocated
==272669== 
==272669== LEAK SUMMARY:
==272669==    definitely lost: 4,448 bytes in 139 blocks
==272669==    indirectly lost: 0 bytes in 0 blocks
==272669==      possibly lost: 719,088 bytes in 4,998 blocks
==272669==    still reachable: 382,436 bytes in 1,255 blocks
==272669==         suppressed: 0 bytes in 0 blocks
==272669== Rerun with --leak-check=full to see details of leaked memory
==272669== 
==272669== For lists of detected and suppressed errors, rerun with: -s
==272669== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Which in turn points to gcc,libgomp or at least this is my best guess at the
moment, the error is persistent when trying to build for different versions of
php.

System Environment:
- OS Ubuntu 23.04
- gcc: gcc version 12.2.0 (Ubuntu 12.2.0-17ubuntu1)
- php versions tried to build: 8.2.5, 8.1.17, 8.1.18
- imagick version: 3.7.0

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/Imagick/
                   |                            |imagick/issues/609

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
IIRC

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Could be a glibc issue too.

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc/2015-February/216464.html

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As mentioned by Andrew, this is a user error.
libgomp can be only dlopened in threaded apps if there is still space in the
static TLS surplus, which unfortunately some versions of glibc use even for
normal TLS rather than just static TLS.
So, LD_PRELOAD=libgomp.so.1, or link the program with libgomp.so.1 rather than
just its libraries, or dlopen it before spawning threads.
This is how glibc behaves, and unless we want to slow down libgomp extremely,
there is nothing that can be done about it on the GCC side.

[Bug libgomp/109634] Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
I remember Glibc used to issue a readable diagnostic in that case ("cannot
allocate memory in static TLS block"). Worth reporting to Glibc if that part
regressed and the diagnostic is no longer available (at least I don't see it in
the linked Github issue).

What is actually happening here? Valgrind catches a null pointer dereference,
but where is that null coming from? Is the dynamic linker invoking constructors
with TLS pointer set to null, instead of aborting?