php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76560 Absurd memory allocation during PEAR step of "make install"
Submitted: 2018-07-02 02:25 UTC Modified: 2020-04-19 04:22 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: php at nearlyfreespeech dot net Assigned: cmb (profile)
Status: No Feedback Package: Compile Failure
PHP Version: 7.3.0beta2 OS: FreeBSD
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: php at nearlyfreespeech dot net
New email:
PHP Version: OS:

 

 [2018-07-02 02:25 UTC] php at nearlyfreespeech dot net
Description:
------------
With a clean pull from the 7.3.0alpha2 tag, everything builds OK, but during the install, there is an error during a memory allocation attempt:

Fatal error: Out of memory (allocated 8388608) (tried to allocate 12298126926392233984 bytes) in phar://install-pear-nozlib.phar/PEAR/Config.php on line 1032

That's a lot of memory.  Seems like some sort of 64 bit related error?

The specific install command that causes the error is:

/data/build/php-src/sapi/cli/php -n -dshort_open_tag=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0 pear/install-pear-nozlib.phar -d "/usr/local/php/7.3.0alpha2/lib" -b "/usr/local/php/7.3.0alpha2/bin" -dp a -ds a

The configure command used was:

'./configure' '--with-apxs2=/usr/local/apache/2.4/bin/apxs' '--prefix=/usr/local/php/7.3.0alpha2' '--includedir=/usr/local/php/7.3.0alpha2/include/' '--libdir=/usr/local/php/7.3.0alpha2' '--libexecdir=/usr/local/php/7.3.0alpha2/libexec/' '--mandir=/usr/local/php/7.3.0alpha2/man/' '--sbindir=/usr/local/php/7.3.0alpha2/bin/' '--with-config-file-path=/usr/local/php/7.3.0alpha2/etc/' '--disable-all' '--with-openssl' '--enable-cgi' '--enable-cli' '--enable-fpm' '--enable-hash' '--enable-zlib' '--enable-phpdbg' '--enable-libxml' '--enable-xml' '--enable-simplexml' '--enable-pdo' '--with-pdo-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pear=/usr/local/php/7.3.0alpha2/lib' '--with-pcre-regex'

The full output of "make install" is in the "actual result" section.

Is there anything else we can do to help narrow down what might be causing this?


Actual result:
--------------
Installing PHP SAPI module:       apache2handler
/usr/local/apache/2.4.33/build/instdso.sh SH_LIBTOOL='/usr/local/share/apr/build-1/libtool' libphp7.la /usr/local/apache/2.4.33/libexec
/usr/local/share/apr/build-1/libtool --mode=install install libphp7.la /usr/local/apache/2.4.33/libexec/
libtool: install: install .libs/libphp7.so /usr/local/apache/2.4.33/libexec/libphp7.so
libtool: install: install .libs/libphp7.lai /usr/local/apache/2.4.33/libexec/libphp7.la
libtool: warning: remember to run 'libtool --finish /data/build/php-src/libs'
chmod 755 /usr/local/apache/2.4.33/libexec/libphp7.so
[activating module `php7' in /usr/local/apache/2.4.33/conf/httpd.conf]
Installing PHP CLI binary:        /usr/local/php/7.3.0alpha2/bin/
Installing PHP CLI man page:      /usr/local/php/7.3.0alpha2/man/man1/
Installing PHP FPM binary:        /usr/local/php/7.3.0alpha2/bin/
Installing PHP FPM defconfig:     /usr/local/php/7.3.0alpha2/etc/
Installing PHP FPM man page:      /usr/local/php/7.3.0alpha2/man/man8/
Installing PHP FPM status page:   /usr/local/php/7.3.0alpha2/php/php/fpm/
Installing phpdbg binary:         /usr/local/php/7.3.0alpha2/bin/
Installing phpdbg man page:       /usr/local/php/7.3.0alpha2/man/man1/
Installing PHP CGI binary:        /usr/local/php/7.3.0alpha2/bin/
Installing PHP CGI man page:      /usr/local/php/7.3.0alpha2/man/man1/
Installing build environment:     /usr/local/php/7.3.0alpha2/build/
Installing header files:          /usr/local/php/7.3.0alpha2/include/php/
Installing helper programs:       /usr/local/php/7.3.0alpha2/bin/
  program: phpize
  program: php-config
Installing man pages:             /usr/local/php/7.3.0alpha2/man/man1/
  page: phpize.1
  page: php-config.1
Installing PEAR environment:      /usr/local/php/7.3.0alpha2/lib/
[PEAR] Archive_Tar    - installed: 1.4.3
[PEAR] Console_Getopt - installed: 1.4.1
[PEAR] Structures_Graph- installed: 1.1.1
[PEAR] XML_Util       - installed: 1.4.2
[PEAR] PEAR           - installed: 1.10.5

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

Fatal error: Out of memory (allocated 8388608) (tried to allocate 12298126926392233984 bytes) in phar://install-pear-nozlib.phar/PEAR/Config.php on line 1032
*** Error code 255

Stop.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-07-02 09:13 UTC] dc dot link at yahoo dot fr
As a FreeBSD user here my memory settings.
...
hw.physmem: 8435605504
hw.usermem: 5781114880
hw.realmem: 8589934592
...
Was able to install.
Might need to check maybe the /etc/login.conf settings ? Otherwise no clues.
 [2018-07-03 01:22 UTC] php at nearlyfreespeech dot net
Compiling with --enable-debug showed that the code is dying in erealloc2() as called by zend_smart_str:

Fatal error: Out of memory (allocated 10485760) at /data/build/php-src/Zend/zend_smart_str.c:41 (tried to allocate 13849063123295670240 bytes) in phar://install-pear-nozlib.phar/PEAR/Config.php on line 1032

Adding some asserts and running under gdb produced a backtrace:

#0  0x000000080254284a in thr_kill () from /lib/libc.so.7
#1  0x0000000802542814 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x0000000802542789 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x00000008025bde61 in __assert (func=<value optimized out>,
    file=<value optimized out>, line=<value optimized out>,
    failedexpr=<value optimized out>) at /usr/src/lib/libc/gen/assert.c:51
#4  0x00000000007e0156 in smart_str_erealloc (str=0x7fffffffc500,
    len=13849063123295666318) at zend_smart_str.c:43
#5  0x00000000006802c6 in smart_str_alloc (str=0x7fffffffc500,
    len=13849063123295666318, persistent=0 '\0') at zend_smart_str.h:69
#6  0x000000000067d51a in smart_str_appendl_ex (dest=0x7fffffffc500,
    str=0x5d0a78 "\211�1�A�\003", len=13849063123295666180, persistent=0 '\0')
    at zend_smart_str.h:120
#7  0x00000000006807b5 in php_var_serialize_string (buf=0x7fffffffc500,
    str=0x5d0a78 "\211�1�A�\003", len=13849063123295666180) at var.c:654
#8  0x000000000067e3f2 in php_var_serialize_intern (buf=0x7fffffffc500,
    struc=0x8032e8e40, var_hash=0x8036e87e0) at var.c:859
#9  0x000000000067eb4b in php_var_serialize_intern (buf=0x7fffffffc500,
    struc=0x803021980, var_hash=0x8036e87e0) at var.c:969
#10 0x000000000067e158 in php_var_serialize (buf=0x7fffffffc500,
    struc=0x803021980, data=0x7fffffffc510) at var.c:988
#11 0x000000000067ef92 in zif_serialize (execute_data=0x803021930,
    return_value=0x803021890) at var.c:1035
#12 0x0000000000832f67 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER (
) at zend_vm_execute.h:690
#13 0x00000000007e2dcb in execute_ex (ex=0x80301f030)
    at zend_vm_execute.h:54407
#14 0x00000000007e2f9d in zend_execute (op_array=0x80307d400, return_value=0x0)
    at zend_vm_execute.h:59962
#15 0x00000000007765a5 in zend_execute_scripts (type=8, retval=0x0,
    file_count=3) at zend.c:1564
#16 0x00000000006ce017 in php_execute_script (primary_file=0x7fffffffe6a0)
    at main.c:2467
#17 0x0000000000886a54 in do_cli (argc=16, argv=0x7fffffffe8d8)
    at php_cli.c:1002
#18 0x0000000000885afd in main (argc=16, argv=0x7fffffffe8d8) at php_cli.c:1395

The value for "len" at the point of assertion failure is clearly bogus:

(gdb) print len
$2 = 13849063123295666318

This value can be traced up the call stack; invalid lengths are visible through the call stack all the way to php_var_serialize_string:

#7  0x00000000006807b5 in php_var_serialize_string (buf=0x7fffffffc500,
    str=0x5d0a78 "\211�1�A�\003", len=13849063123295666180) at var.c:654

This function is called from php_var_serialize_intern.  The len parameter is generated by the macro expression Z_STRLEN_P(struc) at var.c:654.

(gdb) print struc
$3 = (zval *) 0x8032e8e40
(gdb) print *struc
$4 = {value = {lval = 6097504, dval = 3.0125672517795842e-317,
    counted = 0x5d0a60, str = 0x5d0a60, arr = 0x5d0a60, obj = 0x5d0a60,
    res = 0x5d0a60, ref = 0x5d0a60, ast = 0x5d0a60, zv = 0x5d0a60,
    ptr = 0x5d0a60, ce = 0x5d0a60, func = 0x5d0a60, ww = {w1 = 6097504,
      w2 = 0}}, u1 = {v = {type = 6 '\006', type_flags = 0 '\0', u = {
        call_info = 0, extra = 0}}, type_info = 6}, u2 = {next = 4294967295,
    cache_slot = 4294967295, opline_num = 4294967295, lineno = 4294967295,
    num_args = 4294967295, fe_pos = 4294967295, fe_iter_idx = 4294967295,
    access_flags = 4294967295, property_guard = 4294967295,
    extra = 4294967295}}

Z_STRLEN_P(struc) macro-expands to: Z_STRLEN(*(struc))

Z_STRLEN(*(struc)) macro-expands to: ZSTR_LEN(Z_STR(*(struc)))

Z_STR(*(struc)) macro-expands to: (*(struc)).value.str
which simplifies to: struc->value.str

ZSTR_LEN(struc->value.str) macro-expands to: (struc->value.str)->len

This checks out with gdb:

(gdb) print (struc->value.str)->len
$5 = 13849063123295666180

The zval does claim to be a string:

(gdb) print struc->u1
$12 = {v = {type = 6 '\006', type_flags = 0 '\0', u = {call_info = 0,
      extra = 0}}, type_info = 6}

But it looks like a garbage pointer:

(gdb) print struc->value.str
$7 = (zend_string *) 0x5d0a60
(gdb) print *struc->value.str
$8 = {gc = {refcount = 3850979413, u = {type_info = 3773072200}},
  h = 13258597314268528968, len = 13849063123295666180,
  val = 0x5d0a78 "\211�1�A�\003"}

Stepping up to frame 9 (serializing the parent structure) gives us some clue as to what is going on at the time of the crash:

(gdb) print *buf->s
$17 = {gc = {refcount = 1, u = {type_info = 6}}, h = 0, len = 138,
  val = 0x803454918 "a:33:{s:15:\"default_channel\";s:12:\"pear.php.net\";s:16:\"preferred_mirror\";s:12:\"pear.php.net\";s:13:\"remote_config\";s:13849063123295666180:\""}

So it looks like it's maybe trying to serialize the config for pear.conf and it thinks it has a 12-exabyte value for remote_config.  Looking at working pear.conf from earlier versions, that string should probably be empty.

Unfortunately, wherever this value was set isn't in the callstack.

Does this shed any light on the possible issue?

If it helps, a script that reliably reproduces the problem is shown below:

#!/bin/sh
export CC CXX CFLAGS CXXFLAGS EXTENSION_DIR

CC=clang
CFLAGS="-g -O2 -fno-strict-aliasing -DFLUGEL_HORN"
CXX=clang++
CXXFLAGS="-g -O2 -fno-strict-aliasing -DFLUGEL_HORN"

PREFIX="/usr/local/php/7.3.0alpha2"
EXTENSION_DIR="${PREFIX}/libexec"

if [ ! -f ./configure ]
then
	PHP_AUTOCONF=autoconf-2.69 PHP_AUTOHEADER=autoheader-2.69 ./buildconf --force
fi

./configure \
--prefix=${PREFIX} \
--includedir=${PREFIX}/include/ \
--libdir=${PREFIX} \
--libexecdir=${PREFIX}/libexec/ \
--mandir=${PREFIX}/man/ \
--sbindir=${PREFIX}/bin/ \
--with-config-file-path=${PREFIX}/etc/ \
--disable-all \
--enable-debug \
--with-openssl \
--enable-cli \
--enable-xml \
--enable-libxml \
--with-pear=${PREFIX}/lib

make

rm -r ${PREFIX}

make install
 [2018-07-03 10:44 UTC] dc dot link at yahoo dot fr
Was not able to reproduce the crash in my case the len is much less important (i.e 204). Test on FreeBSD 10.4 release (if it counts ... might depends if you run a 12 dev SNAPSHOT for example).
 [2018-07-04 21:37 UTC] php at nearlyfreespeech dot net
This problem has been reproduced on FreeBSD stable releases 11.1 (clang 4.0) and FreeBSD 11.2 (clang 6.0).

It appears not to occur if 7.3.0alpha2 is compiled with the lang/gcc7 port, and it does not occur with clang on the heads of the PHP-7.1 or PHP-7.2 branches.
 [2018-07-17 07:10 UTC] php at nearlyfreespeech dot net
-PHP Version: 7.3.0alpha2 +PHP Version: 7.3.0alpha3
 [2018-07-17 07:10 UTC] php at nearlyfreespeech dot net
This was retested and it still occurs on 7.3.0alpha3.
 [2018-07-19 13:52 UTC] dc dot link at yahoo dot fr
Might be better to open an issue on github to attract potential other FreeBSD users.
 [2018-07-19 15:59 UTC] dc dot link at yahoo dot fr
Forget my comment ... confused with Python ...
 [2018-07-20 04:44 UTC] dc dot link at yahoo dot fr
Question out of curiosity, can you build clang from source and try ? Maybe this issue has been solved

https://github.com/llvm-mirror/clang/commit/f9af50d37f8d3ae675069543ba14b2a6ace05428
 [2018-07-27 09:14 UTC] php-bsd1244 at yahoo dot de
Hi was able to reproduce the error with FreeBSD 11.2 in conjunction with clang. No issues with gcc indeed.
 [2018-08-29 21:55 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2018-08-29 21:55 UTC] cmb@php.net
There have been several FreeBSD related fixes lately, so this
issue might have been resolved.  Or can anybody still reproduce
this?
 [2018-08-30 01:12 UTC] php at nearlyfreespeech dot net
-Status: Feedback +Status: Assigned -PHP Version: 7.3.0alpha3 +PHP Version: 7.3.0beta2
 [2018-08-30 01:12 UTC] php at nearlyfreespeech dot net
As of commit 566a75e97c7df74d3172b0b8442d857105123135 to the PHP-7.3 branch (after beta2), this issue is still reproducible with clang, but not with gcc.
 [2018-08-30 09:28 UTC] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2018-08-30 09:28 UTC] cmb@php.net
Thanks for the update!
 [2018-11-12 08:22 UTC] pascal dot christen at hostpoint dot ch
Any news here? Still persists with rc5
 [2020-04-08 11:24 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-04-08 11:24 UTC] cmb@php.net
Quite some time has passed; does this issue still persist?
 [2020-04-19 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 08:01:29 2024 UTC