public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgomp/109634] New: Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime
@ 2023-04-26 15:20 gcc_bugzilla at murphyslantech dot de
  2023-04-26 15:22 ` [Bug libgomp/109634] " pinskia at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: gcc_bugzilla at murphyslantech dot de @ 2023-04-26 15:20 UTC (permalink / raw)
  To: gcc-bugs

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-04-27  7:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-26 15:20 [Bug libgomp/109634] New: Linking Imagick for PHP compiles fine but gives segfault caused by libgomp on runtime gcc_bugzilla at murphyslantech dot de
2023-04-26 15:22 ` [Bug libgomp/109634] " pinskia at gcc dot gnu.org
2023-04-26 15:41 ` pinskia at gcc dot gnu.org
2023-04-26 16:36 ` pinskia at gcc dot gnu.org
2023-04-27  6:45 ` jakub at gcc dot gnu.org
2023-04-27  7:03 ` amonakov at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).