Edit report at https://bugs.php.net/bug.php?id=79034&edit=1
ID: 79034
Comment by: bugreports at gmail dot com
Reported by: bugreports at gmail dot com
Summary: PHP Fatal error: CPU doesn't support SSE2 in
Unknown on line 0
Status: No Feedback
Type: Bug
Package: opcache
Operating System: Linux
PHP Version: master-Git-2019-12-26 (Git)
Block user comment: N
Private report: N
New Comment:
FWIW:
while the performance is horrible compared to 7.4 in the identical setup depending on
"opcache.jit" setting it becomes stable
my first hope was disable "enable AVX instruction generation" (because there was https://bugs.php.net/bug.php?id=78769) alone would
be the trigger but it isn't
in case the problem is in that context: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (IvyBrdige with AVX
but no AVX2) and the binary is built in a VMware Workstation guest running Fedora 31, the weird
behavior is on the guest as well as on the host
-------------------------------------------------------------------
CPU specific optimization flags: none
JIT trigger: JIT all functions on first script load
-------------------------------------------------------------------
corruption: opcache.jit = 1235
corruption: opcache.jit = 0235
no errors: opcache.jit = 0205
-------------------------------------------------------------------
PHP 7.4 (PRELOAD: BASE, FULL, API)
3672,59
3702,19
3671,93
3701,91
3681,59
AVG: 3686,04
-------------------------------------------------------------------
PHP 8.0 (PRELOAD: BASE, FULL, API - JIT not compiled at all)
3711,10
3666,56
3717,44
3657,81
3712,25
-------------------------------------------------------------------
PHP 8.0 (PRELOAD: BASE, FULL, API - JIT 0205)
3575,23
3465,11
3591,48
3621,69
3590,75
AVG: 3568,85
-------------------------------------------------------------------
Previous Comments:
------------------------------------------------------------------------
[2020-01-19 04:22:04] 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.
------------------------------------------------------------------------
[2020-01-15 18:51:00] bugreports at gmail dot com
foregt it, it#s a gmabling machine with my code and the 3 succesful pgo builds where just random,
it's now at "CPU doesn't support SSE2" again, build without JIT for now
------------------------------------------------------------------------
[2020-01-15 18:37:14] bugreports at gmail dot com
using "lld" seems to be part of the problem
https://bugs.php.net/bug.php?id=79092 while
lld-8.0.0-1.fc30.x86_64 is used here pointed me to try without lld
- export LD="ld.lld"
+ export LD=ld.gold
---------------------------
but there is still stuff broken in the final PGO binary (latest master) while the intermdiate
"profile-gen" suceeds on the whole testsuite and that is currently reproduceable but as
said only in ta optimized "profile-use" build
TypeError: substr() expects parameter 1 to be string, null given in api_cache.php:705
line 705: if($cache_key !== NULL && substr($cache_key, 0, $hash_length) === $hash)
TypeError: substr() expects parameter 1 to be string, null given in api_cache.php:707
line 705: if($cache_key !== NULL)
line 706: {
line 707: if(substr($cache_key, 0, $hash_length) === $hash)
---------------------------
that code is part of the apcu-caching layer and follows "$inventory =
apcu_fetch('shm_inventory')" which is looped with "foreach($inventory as
$cache_key=>$shm_key)" and so move apcu out of the game don't make any sense
tar xzf /rpmbuild/SOURCES/apcu-%{apcu_version}.tgz
mv apcu-%{apcu_version} ./ext/apcu
---------------------------
sadly another build without changes didn't suceed the testsuit ebecause of random type errors
honestly i have no idea what's going on here
TypeError: strtolower() expects parameter 1 to be string, null given
------------------------------------------------------------------------
[2020-01-09 10:00:38] nikic@php.net
The referenced change is not at fault, it exposed a bug somewhere else. Unless you are interested in
debugging this issue (I can provide instructions, though the first thing to do is of course switch
to a debug build), this will only be resolved once someone qualified happens to reproduce this in
other code.
------------------------------------------------------------------------
[2020-01-09 09:28:13] bugreports at gmail dot com
PHP 8.0 MASTER is still broken, i don't get why a offending change after which a predictable
environment which worked before with 7.2/7.3/7.4/8.0 HEAD with and without JIT worked perfectly fine
has now all sort of memory curruptions and sgefaults isn't simply reverted that long
i used to build 7.2-8.0 nearly daily for weeks until that breakage
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=79034
--
Edit this bug report at https://bugs.php.net/bug.php?id=79034&edit=1