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.

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

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).

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.

This was retested and it still occurs on 7.3.0alpha3.

Might be better to open an issue on github to attract potential other FreeBSD users.

Forget my comment ... confused with Python ...

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

Hi was able to reproduce the error with FreeBSD 11.2 in conjunction with clang. No issues with gcc indeed.

There have been several FreeBSD related fixes lately, so this
issue might have been resolved.  Or can anybody still reproduce
this?

As of commit 566a75e97c7df74d3172b0b8442d857105123135 to the PHP-7.3 branch (after beta2), this issue is still reproducible with clang, but not with gcc.

Thanks for the update!

Any news here? Still persists with rc5

Quite some time has passed; does this issue still persist?

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.