php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #76392 Error relocating sapi/cli/php: unsupported relocation type 37
Submitted: 2018-05-30 08:29 UTC Modified: 2018-06-21 11:44 UTC
Votes:4
Avg. Score:3.8 ± 1.3
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:4 (100.0%)
From: peterkokot at gmail dot com Assigned: laruence (profile)
Status: Closed Package: *Compile Issues
PHP Version: 7.3.0alpha2 OS: Alpine 3.7
Private report: No CVE-ID: None
View Developer Edit
 [2018-05-30 08:29 UTC] peterkokot at gmail dot com 
Description:
------------
When building PHP on Alpine Linux 3.7 the compilation goes through ok:

  ./buildconf
  ./configure --disable-all
  make

but then the following appears when running CLI SAPI:

  ./sapi/cli/php -v
  Error relocating sapi/cli/php: unsupported relocation type 37

and exits with 127 code.


When running valgrind --leak-check=full --show-leak-kinds=all sapi/cli/php -v

/opt/php-src # valgrind --leak-check=full --show-leak-kinds=all sapi/cli/php -v
==22== Memcheck, a memory error detector
==22== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==22== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==22== Command: sapi/cli/php -v
==22== 
==22== Invalid free() / delete / delete[] / realloc()
==22==    at 0x4C939EA: free (vg_replace_malloc.c:530)
==22==    by 0x405807B: ??? (in /lib/ld-musl-x86_64.so.1)
==22==  Address 0x4e9b180 is in a rw- mapped file /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so segment
==22== 
Error relocating sapi/cli/php: unsupported relocation type 37
Error relocating sapi/cli/php: unsupported relocation type 37
Error relocating sapi/cli/php: unsupported relocation type 37
Error relocating sapi/cli/php: unsupported relocation type 37
==22== 
==22== HEAP SUMMARY:
==22==     in use at exit: 404 bytes in 1 blocks
==22==   total heap usage: 1 allocs, 1 frees, 404 bytes allocated
==22== 
==22== 404 bytes in 1 blocks are still reachable in loss record 1 of 1
==22==    at 0x4C9461F: calloc (vg_replace_malloc.c:711)
==22==    by 0x40591A7: ??? (in /lib/ld-musl-x86_64.so.1)
==22==    by 0x4059E4F: __dls3 (in /lib/ld-musl-x86_64.so.1)
==22==    by 0x40117DF: ??? (in /lib/ld-musl-x86_64.so.1)
==22== 
==22== LEAK SUMMARY:
==22==    definitely lost: 0 bytes in 0 blocks
==22==    indirectly lost: 0 bytes in 0 blocks
==22==      possibly lost: 0 bytes in 0 blocks
==22==    still reachable: 404 bytes in 1 blocks
==22==         suppressed: 0 bytes in 0 blocks
==22== 
==22== For counts of detected and suppressed errors, rerun with: -v
==22== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


ldd shows the following:

  ldd sapi/cli/php

  /lib/ld-musl-x86_64.so.1 (0x7f82e4eff000)
      libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f82e4eff000)
  Error relocating sapi/cli/php: unsupported relocation type 37
  Error relocating sapi/cli/php: unsupported relocation type 37
  Error relocating sapi/cli/php: unsupported relocation type 37
  Error relocating sapi/cli/php: unsupported relocation type 37


Expected result:
----------------
exit with code 0

Actual result:
--------------
Error relocating sapi/cli/php: unsupported relocation type 37

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-30 11:47 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2018-05-30 11:47 UTC] cmb@php.net 
Please try `./configure --disable-all --without-pcre-jit` (see
also the respective note in
<http://php.net/manual/en/install.unix.php>).
 [2018-05-30 14:47 UTC] peterkokot at gmail dot com 
It's the same also when adding the --without-pcre-jit This is x86 64bit architecture so the pcre-jit should be an issue only on s390x.
 [2018-05-30 16:17 UTC] cmb@php.net
-Status: Feedback +Status: Open -Assigned To: cmb +Assigned To:
 [2018-05-30 16:17 UTC] cmb@php.net 
Thanks for trying.
 [2018-06-20 17:11 UTC] cmb@php.net 
Peter, does this affect master/PHP 7.3 only?  If so, could you
please check whether commit a6e86f7[1] is the first one to cause
this issue?

[1] <http://git.php.net/?p=php-src.git;a=commit;h=a6e86f7a3f954a5cc05508228572e9f1db5d2771>
 [2018-06-20 21:09 UTC] peterkokot at gmail dot com 
With the mentioned commit it outputs only one error. With latest master as of this writing it outputs 4 mentioned errors.

However, now I've made a bit of a progress in identifying what's one of the problems. The first identified problematic commit is 98aa3a6[1]

Before that it works correctly, and with this commit it outputs a single error:
Error relocating sapi/cli/php: unsupported relocation type 37

[1] http://git.php.net/?p=php-src.git;a=commit;h=98aa3a65c4e68e4cd50ab62221a409e4b74cec65

If anyone has any clue... I'm checking out what's up with that...
 [2018-06-20 21:32 UTC] cmb@php.net 
Great, thanks!  It seems to me that __attribute__((ifunc(…))) is
not supported by this runtime.  To verify this, consider to remove
the ifunc support detection[1].

[1] <https://github.com/php/php-src/blob/98aa3a65c4e68e4cd50ab62221a409e4b74cec65/build/ax_gcc_func_attribute.m4#L152-L156>
 [2018-06-20 22:00 UTC] peterkokot at gmail dot com 
Yes, verified. Removing the ifunc lines from the ax_gcc_func_attribute.m4 file works as it should then. The buildconf script outputs few warnings but then everthing goes normally through and compiles.

buildconf: checking installation...
buildconf: autoconf version 2.69 (ok)
rebuilding aclocal.m4
rebuilding configure
configure.ac:584: warning: Unsupported attribute ifunc, the test may fail
../../lib/autoconf/lang.m4:224: AC_LANG_SOURCE is expanded from...
../../lib/autoconf/lang.m4:241: AC_LANG_PROGRAM is expanded from...
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
build/ax_gcc_func_attribute.m4:82: AX_GCC_FUNC_ATTRIBUTE is expanded from...
rebuilding main/php_config.h.in
configure.ac:584: warning: Unsupported attribute ifunc, the test may fail
../../lib/autoconf/lang.m4:224: AC_LANG_SOURCE is expanded from...
../../lib/autoconf/lang.m4:241: AC_LANG_PROGRAM is expanded from...
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
../../lib/autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
build/ax_gcc_func_attribute.m4:82: AX_GCC_FUNC_ATTRIBUTE is expanded from...
 [2018-06-21 10:45 UTC] marcel_989 at hotmail dot com 
I'm experiencing this error on PHP 7.3 alpha1 and alpha2 and Alpine Linux 3.6. However, I'm not even able to compile the executable: the error pops up during the linkage phase.


Dockerfile that reproduces the crash: https://pastebin.com/raw/ES8iFJe8

Build log (I chopped off most compilation lines, is was too much for PasteBin): https://pastebin.com/raw/ny4Jt43c
 [2018-06-21 10:56 UTC] cmb@php.net
-Status: Open +Status: Verified -Assigned To: +Assigned To: laruence
 [2018-06-21 10:56 UTC] cmb@php.net 
@laruence, could you please have a look at this?
 [2018-06-21 10:57 UTC] cmb@php.net
-PHP Version: master-Git-2018-05-30 (Git) +PHP Version: PHP-7.3.0alpha2
 [2018-06-21 10:57 UTC] cmb@php.net
-PHP Version: PHP-7.3.0alpha2 +PHP Version: 7.3.0alpha2
 [2018-06-21 11:32 UTC] laruence@php.net 
So building PHP with ifunc supported environment and run it in a environment which is not supporting ifunc? (STT_GNU_IFUNC)
 [2018-06-21 11:44 UTC] cmb@php.net 
It appears that the *compiler* supports ifunc, but the *runtime*
does not.  Instead of only checking whether ifunc can be
compiled[1], we may need to actually run the resulting executable
and check the status code.

[1] <https://github.com/php/php-src/blob/98aa3a65c4e68e4cd50ab62221a409e4b74cec65/build/ax_gcc_func_attribute.m4#L152-L156>
 [2018-06-25 10:08 UTC] f dot bosch at genkgo dot nl 
The weird thing is that when you use the same methodology for PHP 7.2, there is no problem. See the official Dockerfile for PHP 7.2 on Alpine 3.7. https://github.com/docker-library/php/blob/master/7.2/alpine3.7/cli/Dockerfile. So something must have changed in the meanwhile.

Now I cannot remember for sure, but I believe this is also true for Debian Stretch. I tried to build PHP SRC master with Stretch, based on the official Stretch Dockerfile with some extra deps, but that failed too. Same error. I will try to confirm this.
 [2018-06-28 13:31 UTC] peterkokot at gmail dot com 
Pull request:
https://github.com/php/php-src/pull/3349

On Debian Stretch it works ok, since these systems include glibc which has function attributes.
 [2018-07-07 09:32 UTC] nikic@php.net 
Automatic comment on behalf of peterkokot@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=67352cb2c01706b75d9a6f2793a2022f4751e355
Log: Fix bug #76392
 [2018-07-07 09:32 UTC] nikic@php.net
-Status: Verified +Status: Closed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 16:01:28 2024 UTC