You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dennis Clarke <dc...@blastwave.org> on 2018/10/18 19:55:45 UTC
httpd and php integration
On 10/18/2018 03:42 PM, Rainer Jung wrote:
> Am 18.10.2018 um 21:18 schrieb Dennis Clarke:
>> On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
>>> php: "5.6.38"
>>
> I do build PHP 7.x myself including recent library versions both on some
> Linux platforms as well as on Solaris Sparc. But the typical use is via
> PHP-FPM, not mod_php. So httpd integration is done via mod_proxy_fcgi
> which is part of httpd nowadays. I do not test PHP with the httpd test
> suite, only with the tests that come with PHP itself.
Yes, I see the php-fpm approach and ye old mod_php was fine for php 5.x
world but the world has moved onwards.
> When running the test suite I typically get about 50-80 test failures on
> Linux and 150-200 test failures on Solaris (of about 13000 non-skipped
> tests).
I get outright SIGBUS core dump :-(
beta $ TEST_PHP_EXECUTABLE=sapi/cli/php sapi/cli/php run-tests.php
=====================================================================
PHP : sapi/cli/php
PHP_SAPI : cli
PHP_VERSION : 7.2.8
ZEND_VERSION: 3.2.0
PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
INI actual : /usr/local/lib/php.ini
More .INIs :
---------------------------------------------------------------------
PHP :
/usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001/sapi/phpdbg/phpdbg
PHP_SAPI : phpdbg
PHP_VERSION : 7.2.8
ZEND_VERSION: 3.2.0
PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
INI actual : /usr/local/lib/php.ini
More .INIs :
---------------------------------------------------------------------
CWD : /usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001
Extra dirs :
VALGRIND : Not used
=====================================================================
TIME START 2018-10-18 19:18:58
=====================================================================
Bus Error(coredump)
beta $
beta $ dbx sapi/cli/php
time_1539890338-pid_2068-uid_16411-gid_20002-fid_php.core
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 8.2' in
your .dbxrc
Reading php
core file header read successfully
Reading ld.so.1
Reading libresolv.so.2
Reading librt.so.1
Reading libm.so.2
Reading libnsl.so.1
Reading libsocket.so.1
Reading libz.so.1.2.8
Reading libxml2.so.2.9.2
Reading liblzma.so.5.2.1
Reading libpthread.so.1
Reading libiconv.so.2.6.0
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libc_psr.so.1
Reading en_US.UTF-8.so.3
Reading methods_unicode.so.3
t@1 (l@1) program terminated by signal BUS (invalid address alignment)
Current function is set_label
630 label->next = NULL;
(dbx) where
current thread: t@1
=>[1] set_label(label = 0x101ffa82c, compiler = 0x101ff9780), line 630
in "sljitLir.c"
[2] sljit_emit_label(compiler = 0x101ff9780), line 1251 in
"sljitNativeSPARC_common.c"
[3] php__pcre_jit_compile(re = 0x101ff9570, extra = 0x101ff9600, mode
= 0), line 11081 in "pcre_jit_compile.c"
[4] php_pcre_study(external_re = 0x101ff9570, options = 1, errorptr =
0xffffffff7fffdb10), line 1630 in "pcre_study.c"
[5] pcre_get_compiled_regex_cache(regex = 0xffffffff7d0b5630), line
548 in "php_pcre.c"
[6] php_do_pcre_match(execute_data = 0xffffffff7d023810, return_value
= 0xffffffff7d01efa0, global = 0), line 729 in "php_pcre.c"
[7] zif_preg_match(execute_data = 0xffffffff7d023810, return_value =
0xffffffff7d01efa0), line 1147 in "php_pcre.c"
[8] ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER(execute_data =
0xffffffff7d01e510), line 617 in "zend_vm_execute.h"
[9] execute_ex(ex = 0xffffffff7d01c030), line 59739 in
"zend_vm_execute.h"
[10] zend_execute(op_array = 0xffffffff7d07e540, return_value =
(nil)), line 63776 in "zend_vm_execute.h"
[11] zend_execute_scripts(type = 8, retval = (nil), file_count = 3,
... = 0x17d06c060, ...), line 1496 in "zend.c"
[12] php_execute_script(primary_file = 0xffffffff7ffff0f8), line 2590
in "main.c"
[13] do_cli(argc = 2, argv = 0x101c8ed20), line 1011 in "php_cli.c"
[14] main(argc = 2, argv = 0x101c8ed20), line 1404 in "php_cli.c"
(dbx) list
630 label->next = NULL;
631 label->size = compiler->size;
632 if (compiler->last_label)
633 compiler->last_label->next = label;
634 else
635 compiler->labels = label;
636 compiler->last_label = label;
637 }
638
639 static SLJIT_INLINE void set_jump(struct sljit_jump *jump,
struct sljit_compiler *compiler, sljit_s32 flags)
(dbx) print label
label = 0x101ffa82c
(dbx) print *label
*label = {
next = (nil)
addr = 0
size = 0
}
(dbx) quit
Which has me wonder how that is possible given that I tend to enforce
a 64-bit alignment with -xmemalign=8s .
Regardless php has been a battle on Solaris sparc. Would love to know
how you managed to get any sort of reasonable results.
>
> I did get some false positive fixed by the PHP people, but got somewhat
> tired of analyzing the big number of failing tests.
>
I have bug reports filed that seem to rot.
Others I follow or try to follow :
https://bugs.php.net/bug.php?id=49184
That never seems to go away :
beta $ cat /tmp/foo.php
<?php
var_dump(
filter_input(INPUT_SERVER,'ENV_NAME',FILTER_SANITIZE_STRING),
$_SERVER['ENV_NAME']
);
?>
beta $ sapi/cli/php /tmp/foo.php
PHP Notice: Undefined index: ENV_NAME in /tmp/foo.php on line 5
NULL
NULL
beta $
beta $ ENV_NAME=foobar sapi/cli/php /tmp/foo.php
NULL
string(6) "foobar"
beta $
beta $ sapi/cli/php --version
PHP 7.2.8 (cli) (built: Aug 15 2018 03:13:17) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
beta $
In any case ... I trust this build of php 7.2.8 about as far as I can
throw it and I can not throw an M4000 very far at all. Or lift it.
Dennis
Re: httpd and php integration
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/18/2018 07:29 PM, Rainer Jung wrote:
> Am 19.10.2018 um 00:46 schrieb Dennis Clarke:
>> On 10/18/2018 04:57 PM, Rainer Jung wrote:
>>> Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
>>> You debugger output shows jump = 0x101e2915c. This address is not
>>> divisible by 8, so it seems it confirms the alignment problem.
>>>
>>
>> 0x101e2915c ??
>>
>
> I'm referring to https://bugs.php.net/bug.php?id=76745 and the line:
>
ah .. I was wondering where you saw that address ... I was looking at my
xterm :-\
> ...
> t@1 (l@1) program terminated by signal BUS (invalid address alignment)
> Current function is set_jump
> 641 jump->next = NULL;
> (dbx) where
> current thread: t@1
> =>[1] set_jump(jump = 0x101e2915c, compiler = 0x101e280b0, flags = 0),
> line 641 in "sljitLir.c"
> ^^^^^^^^^^^^^^^^^^^^^^0x101e2915c^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [2] sljit_emit_jump(compiler = 0x101e280b0, type = 24), line 1320 in
> "sljitNativeSPARC_common.c"
> [3] mainloop_entry(common = 0xffffffff7fffd180, hascrorlf = 0), line
> 3372 in "pcre_jit_compile.c"
> ...
Right.
I will circle back around on this after I see httpd 2.4.37/38/39 built
and running. Don't be surprised if I may have questions and more
odd things. I see a bootstrap of gcc happening tonight.
Dennis
Re: httpd and php integration
Posted by Rainer Jung <ra...@kippdata.de>.
Am 19.10.2018 um 00:46 schrieb Dennis Clarke:
> On 10/18/2018 04:57 PM, Rainer Jung wrote:
>> Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
>> You debugger output shows jump = 0x101e2915c. This address is not
>> divisible by 8, so it seems it confirms the alignment problem.
>>
>
> 0x101e2915c ??
>
> Not sure where you are seeing that but .. I am going back to start over
> with some updates and possibly a new gcc bootstrap and pcre and whatever
> else I can throw at the wall here. Really the Apache 2.4.37 ( today 37
> and tomorrow 38? ) is what I am aiming for.
I'm referring to https://bugs.php.net/bug.php?id=76745 and the line:
...
t@1 (l@1) program terminated by signal BUS (invalid address alignment)
Current function is set_jump
641 jump->next = NULL;
(dbx) where
current thread: t@1
=>[1] set_jump(jump = 0x101e2915c, compiler = 0x101e280b0, flags = 0),
line 641 in "sljitLir.c"
^^^^^^^^^^^^^^^^^^^^^^0x101e2915c^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[2] sljit_emit_jump(compiler = 0x101e280b0, type = 24), line 1320 in
"sljitNativeSPARC_common.c"
[3] mainloop_entry(common = 0xffffffff7fffd180, hascrorlf = 0), line
3372 in "pcre_jit_compile.c"
...
Regards,
Rainer
Re: httpd and php integration
Posted by Dennis Clarke <dc...@blastwave.org>.
On 10/18/2018 04:57 PM, Rainer Jung wrote:
> Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
>> On 10/18/2018 03:42 PM, Rainer Jung wrote:
>>> Am 18.10.2018 um 21:18 schrieb Dennis Clarke:
>>>> On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
>>>>> php: "5.6.38"
>>>>
>>
>>> I do build PHP 7.x myself including recent library versions both on
>>> some Linux platforms as well as on Solaris Sparc. But the typical use
>>> is via PHP-FPM, not mod_php. So httpd integration is done via
>>> mod_proxy_fcgi which is part of httpd nowadays. I do not test PHP
>>> with the httpd test suite, only with the tests that come with PHP
>>> itself.
>>
>> Yes, I see the php-fpm approach and ye old mod_php was fine for php 5.x
>> world but the world has moved onwards.
>>
>>> When running the test suite I typically get about 50-80 test failures
>>> on Linux and 150-200 test failures on Solaris (of about 13000
>>> non-skipped tests).
>>
>> I get outright SIGBUS core dump :-(
>
> Yes, I sometimes get them and try to get them analyzed (by myself) and
> fixed (by the PHP people). On Solaris Sparc the SIGBUS almost always
> comes from bad alignment, where an 8 byte type is not located at an
> address divisible by 8. X86_64 is not sensible to this and of course the
> PHP people do not typically test on Sparc.
*nod*
> Concerning the 7.2.8 failure: the biggest difference between our setups
> is probably the compiler. I wanted to keep deltas to the mostly used
> platform Linux small, so I build using GCC (which I compile myself).
You and I seem to be the last people still bootstrapping gcc on Solaris
sparc but that is another discussion on another maillist ;-)
> The
> alignment in question could well be sensible to the compiler used.
> Furthermore I am doing still 32 bit builds, and it looks like you are
> doing 64 bit builds.
Pure 64-bit has been my way for almost the last decade. I think I waved
farewell to Solaris 8 back in 2008 and that resulted in a near revolt
within "Blastwave" because, well, money. That is an old story. Also we
all thought OpenSolaris was going to change the landscape. Another old
story. However my 64-bit stack has been the floor plan stuff that kept
a small finance company running production software for many years and
that included recent Apache httpd and php and the usual stuff needed for
Wordpress sites and a lot of custom internal stuff. Gets more difficult
every day to deal with updates however and here we are looking at httpd
with tls 1.3 and with httpd ver 2.4.37. All good stuff to be sure.
>
> Looking at your issue
>
> https://bugs.php.net/bug.php?id=76745
>
> I did not myself observe this problem. It looks like a pcre problem,
I was thinking the same and built my own.
beta $ file /usr/local/bin/pcretest
/usr/local/bin/pcretest: ELF 64-bit MSB executable SPARCV9 Version 1,
UltraSPARC3 Extensions Required, dynamically linked, not stripped
beta $
beta $ /usr/local/bin/pcretest -C
PCRE version 8.40 2017-01-11
Compiled with
8-bit support
UTF-8 support
16-bit support
UTF-16 support
32-bit support
UTF-32 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 4
POSIX malloc threshold = 10
Parentheses nest limit = 250
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses heap
beta $
Works very very well. So I am surprised at the alignment. In fact I have
*had* it running neatly for a while. I often wondered what that internal
link size really means ... hrmmm .. 4 ? 32-bit? Could be a red herring.
> not
> really a PHP problem. The pcre they bundle in 7.2.8 is version 8.41.
> Recent for 8.x would be 8.42, but even in 7.2.11 it is still at 8.41. On
> the other hand, I did not find an immediate information, that 8.42 fixes
> an alignment problem in the jit. But it does contain quite a few jit
> changes.
OKay .. I am going back to the source well and perhaps bootstrap GCC 8.x
again and why not? It has been a over a month since I looked.
> You debugger output shows jump = 0x101e2915c. This address is not
> divisible by 8, so it seems it confirms the alignment problem.
>
0x101e2915c ??
Not sure where you are seeing that but .. I am going back to start over
with some updates and possibly a new gcc bootstrap and pcre and whatever
else I can throw at the wall here. Really the Apache 2.4.37 ( today 37
and tomorrow 38? ) is what I am aiming for.
> You could try to reproduce the problem by compiling pcre 8.41 standalone
> and run the pcre test suite.
Yep. That first.
> Uf you can reproduce, you can check,
> whether it is goine in 8.42 and then at least point the php people to
> that finding, asking them for an upgrade. Finally you can also try to
> add pcre 8.42 into your php source tree under ext/pcre/pcrelib.
I may do both. Actually ... now that I think on it.
> It seems
> PHP does not change any of the files, but you would also need to add the
> generated files config.h, pcre_chartables.c and pcre.h. You can probably
> get those by first running configure and maybe also make for a
> standalone pcre 8.42.
All good thinking ... thank you.
>
> Concerning your foo.php script, I get the same results, but it starts
> working when using INPUT_ENV. I don't know what the definition of
> INPUT_SERVER for PHP CLI is. At least for PHP with FCGI it seems to be
> known that INPUT_SERVER doesn't work well. So probably not something
> specific to your build.
Not worth digging into. For now. That would be like moving around the
deck chairs on the Titanic.
Thank you Rainer.
Dennis Clarke
Re: httpd and php integration
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.10.2018 um 21:55 schrieb Dennis Clarke:
> On 10/18/2018 03:42 PM, Rainer Jung wrote:
>> Am 18.10.2018 um 21:18 schrieb Dennis Clarke:
>>> On 10/18/2018 02:12 PM, Daniel Ruggeri wrote:
>>>> php: "5.6.38"
>>>
>
>> I do build PHP 7.x myself including recent library versions both on
>> some Linux platforms as well as on Solaris Sparc. But the typical use
>> is via PHP-FPM, not mod_php. So httpd integration is done via
>> mod_proxy_fcgi which is part of httpd nowadays. I do not test PHP with
>> the httpd test suite, only with the tests that come with PHP itself.
>
> Yes, I see the php-fpm approach and ye old mod_php was fine for php 5.x
> world but the world has moved onwards.
>
>> When running the test suite I typically get about 50-80 test failures
>> on Linux and 150-200 test failures on Solaris (of about 13000
>> non-skipped tests).
>
> I get outright SIGBUS core dump :-(
Yes, I sometimes get them and try to get them analyzed (by myself) and
fixed (by the PHP people). On Solaris Sparc the SIGBUS almost always
comes from bad alignment, where an 8 byte type is not located at an
address divisible by 8. X86_64 is not sensible to this and of course the
PHP people do not typically test on Sparc.
Concerning the 7.2.8 failure: the biggest difference between our setups
is probably the compiler. I wanted to keep deltas to the mostly used
platform Linux small, so I build using GCC (which I compile myself). The
alignment in question could well be sensible to the compiler used.
Furthermore I am doing still 32 bit builds, and it looks like you are
doing 64 bit builds.
Looking at your issue
https://bugs.php.net/bug.php?id=76745
I did not myself observe this problem. It looks like a pcre problem, not
really a PHP problem. The pcre they bundle in 7.2.8 is version 8.41.
Recent for 8.x would be 8.42, but even in 7.2.11 it is still at 8.41. On
the other hand, I did not find an immediate information, that 8.42 fixes
an alignment problem in the jit. But it does contain quite a few jit
changes.
You debugger output shows jump = 0x101e2915c. This address is not
divisible by 8, so it seems it confirms the alignment problem.
You could try to reproduce the problem by compiling pcre 8.41 standalone
and run the pcre test suite. Uf you can reproduce, you can check,
whether it is goine in 8.42 and then at least point the php people to
that finding, asking them for an upgrade. Finally you can also try to
add pcre 8.42 into your php source tree under ext/pcre/pcrelib. It seems
PHP does not change any of the files, but you would also need to add the
generated files config.h, pcre_chartables.c and pcre.h. You can probably
get those by first running configure and maybe also make for a
standalone pcre 8.42.
Concerning your foo.php script, I get the same results, but it starts
working when using INPUT_ENV. I don't know what the definition of
INPUT_SERVER for PHP CLI is. At least for PHP with FCGI it seems to be
known that INPUT_SERVER doesn't work well. So probably not something
specific to your build.
Regards,
Rainer
> beta $ TEST_PHP_EXECUTABLE=sapi/cli/php sapi/cli/php run-tests.php
>
> =====================================================================
> PHP : sapi/cli/php
> PHP_SAPI : cli
> PHP_VERSION : 7.2.8
> ZEND_VERSION: 3.2.0
> PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
> INI actual : /usr/local/lib/php.ini
> More .INIs :
> ---------------------------------------------------------------------
> PHP :
> /usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001/sapi/phpdbg/phpdbg
> PHP_SAPI : phpdbg
> PHP_VERSION : 7.2.8
> ZEND_VERSION: 3.2.0
> PHP_OS : SunOS - SunOS beta 5.10 Generic_150400-61 sun4u
> INI actual : /usr/local/lib/php.ini
> More .INIs :
> ---------------------------------------------------------------------
> CWD : /usr/local/build/php-7.2.8_SunOS5.10_sparc64vii+.001
> Extra dirs :
> VALGRIND : Not used
> =====================================================================
> TIME START 2018-10-18 19:18:58
> =====================================================================
> Bus Error(coredump)
> beta $
> beta $ dbx sapi/cli/php
> time_1539890338-pid_2068-uid_16411-gid_20002-fid_php.core
> For information about new features see `help changes'
> To remove this message, put `dbxenv suppress_startup_message 8.2' in
> your .dbxrc
> Reading php
> core file header read successfully
> Reading ld.so.1
> Reading libresolv.so.2
> Reading librt.so.1
> Reading libm.so.2
> Reading libnsl.so.1
> Reading libsocket.so.1
> Reading libz.so.1.2.8
> Reading libxml2.so.2.9.2
> Reading liblzma.so.5.2.1
> Reading libpthread.so.1
> Reading libiconv.so.2.6.0
> Reading libc.so.1
> Reading libaio.so.1
> Reading libmd.so.1
> Reading libc_psr.so.1
> Reading en_US.UTF-8.so.3
> Reading methods_unicode.so.3
> t@1 (l@1) program terminated by signal BUS (invalid address alignment)
> Current function is set_label
> 630 label->next = NULL;
> (dbx) where
> current thread: t@1
> =>[1] set_label(label = 0x101ffa82c, compiler = 0x101ff9780), line 630
> in "sljitLir.c"
> [2] sljit_emit_label(compiler = 0x101ff9780), line 1251 in
> "sljitNativeSPARC_common.c"
> [3] php__pcre_jit_compile(re = 0x101ff9570, extra = 0x101ff9600, mode
> = 0), line 11081 in "pcre_jit_compile.c"
> [4] php_pcre_study(external_re = 0x101ff9570, options = 1, errorptr =
> 0xffffffff7fffdb10), line 1630 in "pcre_study.c"
> [5] pcre_get_compiled_regex_cache(regex = 0xffffffff7d0b5630), line
> 548 in "php_pcre.c"
> [6] php_do_pcre_match(execute_data = 0xffffffff7d023810, return_value
> = 0xffffffff7d01efa0, global = 0), line 729 in "php_pcre.c"
> [7] zif_preg_match(execute_data = 0xffffffff7d023810, return_value =
> 0xffffffff7d01efa0), line 1147 in "php_pcre.c"
> [8] ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER(execute_data =
> 0xffffffff7d01e510), line 617 in "zend_vm_execute.h"
> [9] execute_ex(ex = 0xffffffff7d01c030), line 59739 in
> "zend_vm_execute.h"
> [10] zend_execute(op_array = 0xffffffff7d07e540, return_value =
> (nil)), line 63776 in "zend_vm_execute.h"
> [11] zend_execute_scripts(type = 8, retval = (nil), file_count = 3,
> ... = 0x17d06c060, ...), line 1496 in "zend.c"
> [12] php_execute_script(primary_file = 0xffffffff7ffff0f8), line 2590
> in "main.c"
> [13] do_cli(argc = 2, argv = 0x101c8ed20), line 1011 in "php_cli.c"
> [14] main(argc = 2, argv = 0x101c8ed20), line 1404 in "php_cli.c"
> (dbx) list
> 630 label->next = NULL;
> 631 label->size = compiler->size;
> 632 if (compiler->last_label)
> 633 compiler->last_label->next = label;
> 634 else
> 635 compiler->labels = label;
> 636 compiler->last_label = label;
> 637 }
> 638
> 639 static SLJIT_INLINE void set_jump(struct sljit_jump *jump,
> struct sljit_compiler *compiler, sljit_s32 flags)
> (dbx) print label
> label = 0x101ffa82c
> (dbx) print *label
> *label = {
> next = (nil)
> addr = 0
> size = 0
> }
> (dbx) quit
>
> Which has me wonder how that is possible given that I tend to enforce
> a 64-bit alignment with -xmemalign=8s .
>
> Regardless php has been a battle on Solaris sparc. Would love to know
> how you managed to get any sort of reasonable results.
>
>>
>> I did get some false positive fixed by the PHP people, but got
>> somewhat tired of analyzing the big number of failing tests.
>>
>
> I have bug reports filed that seem to rot.
> Others I follow or try to follow :
>
> https://bugs.php.net/bug.php?id=49184
>
> That never seems to go away :
>
> beta $ cat /tmp/foo.php
> <?php
>
> var_dump(
> filter_input(INPUT_SERVER,'ENV_NAME',FILTER_SANITIZE_STRING),
> $_SERVER['ENV_NAME']
> );
>
> ?>
> beta $ sapi/cli/php /tmp/foo.php
> PHP Notice: Undefined index: ENV_NAME in /tmp/foo.php on line 5
> NULL
> NULL
> beta $
>
> beta $ ENV_NAME=foobar sapi/cli/php /tmp/foo.php
> NULL
> string(6) "foobar"
> beta $
>
> beta $ sapi/cli/php --version
> PHP 7.2.8 (cli) (built: Aug 15 2018 03:13:17) ( NTS )
> Copyright (c) 1997-2018 The PHP Group
> Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
> beta $
>
> In any case ... I trust this build of php 7.2.8 about as far as I can
> throw it and I can not throw an M4000 very far at all. Or lift it.
>
> Dennis